IRIX and Software

I found it! -- I finally figured it out -- when I wasn't even looking anymore!

For YEARS I have had this issue with the gnome/gtk+ apps on my Octane2 with V6 graphics -- problems with applications such as gedit, gftp, gnumeric and abiword.

The little pixmap icons in the menus, tools bars and icon wondow have been missing ! (or worse blacked out).

The same executable , when run via remote login-in from another SGI such as my Octane with SE graphics or an O2 = no problems.

So it had to be the display. Right?

Well... I just figured out what gtk+ is doing (which, by the way, I know nothing about how to program - just X, Xt and Motif)! It calls a little function called get_best_visual (or something like that) and on lower end graphics machines that is a TrueColor visual with 24 bits in each plane.

But , on the Octane2 with Vpro graphics - that is a visual with 30 bits per plane! But the stupid gtk+ application has assumed no machine would ever have more than 24 bits per plane - so it doesn't convert the data.

The result: f**ked up pixmaps!


Now if only I could find a gtk+ savy programmer who could help me patch the libraries.....hmmm.

What visuals are available via xdpyinfo? Can you change to 24-bit TrueColor?

My root window is 24 bit True Color (and so are the gtk apps when I xwininfo)!
It's just the gtk routines that are confusing the Xlib graphic handling routines...I think.

BTW - I'll be away til monday. Pick it up then...

Yippe! The saints at freeware.sgi.com have answered my prayers. I tracked this error through the source code in gedit and determined it was in imlib . As expected the code looked for the maximum depth of any visual and then assumed that's what was wanted. Unfortunately, I couldn't get my "fix" to build.

Jeff and Dave at sgi rebuilt the library for me with an "official" imlib patch they found.
Problems all gone!
It's unbelivable, how much better all the Gnome/GTK/GDK apps work now on my V6 system.
For any others out there struggling with this issue, I'm told the fixed imlib with be included in a future freeware release, but probably could be had sooner if you are interested.

hello,

i'm also using v6 and gtk but never got such problems.
gftp, sylpheed and the mozilla based apps run fine.

tried with 6.5.20-22...

foetz wrote: gftp, sylpheed and the mozilla based apps run fine.

Those apps must use a mechanism different from imlib because they also were fine for me. Some of the older (GNOME?) apps like gedit, gnumeric, sodipodi and (at one time) Abiword were the worst offenders. Gedit for example would display a black icon window when minimized and an empty set of icons in the toolbar when running. Gnumeric was missing the icons for redo/undo, cell borders, cell colors and a few others. Sodipodi was a mostly blank enigma. If you have time, gives those a try. I'm curious...

yes, seems like it's a gnome issue.
the gnome freeware stuff is quite outdated so maybe it's just from a time vpro features like the color depth were very rare...

squeen wrote: I found it! -- I finally figured it out -- when I wasn't even looking anymore!

But , on the Octane2 with Vpro graphics - that is a visual with 30 bits per plane! But the stupid gtk+ application has assumed no machine would ever have more than 24 bits per plane - so it doesn't convert the data.

The ironic thing that I've found when doing freeware packages, is that not only do many
gtk apps assume no machine would ever have more than 24 bits.. is that most of them assume
that every machine is running exactly 24 bits! If you're using an 8 bit depth as your default,
you'll run into issues as well.

I put the beta package the freeware folks put together to fix the imlib problem onto Neko's FTP/incoming site. If he would be kind enough to move to it the downloads directory, it will hopefully fix your system's issues with the GTK/GNOME apps as well (although it doesn't sound like you are using them much!).

The file is called : fw_imlib.200030821-1501.tardist

squeen wrote: I'm told the fixed imlib with be included in a future freeware release, but probably could be had sooner if you are interested.

so...

if I understand correctly....

FREEWARE IS NOT DEAD !!!!!!!!!

wah000 !!

No freeware is not dead, but the recent wave of lay-offs at SGI has (to my non-insider understanding) left it heavy wounded. Specifically, there are no dedicated resources, just some seriously over-worked volunteers. In that context, I believe that community driven alternates (like what Neko has done with the downloads page!) are happily encouraged.

If anyone has any thoughts regarding how to mirror and augement (with non-SGI contributors) the freeware site -- let's hear them [in a separate thread?].

oooookay... this goes back a million years, relatively.

Anyone know if this is is still an issue? I've been having real issues, specifically with XMMS and the ' badmatch ' errors - since as noted Vpro supports a 30 bit (and I think higher for V8/V12) visual. The common thread seems to be Vpro graphics. I've sett the root window to 'truecolor' and verified with xdpyinfo that the default visual is 24 bits, and although in it's latest version it seems to affect both XMMS versions from freeware and from Nekoware . On an O2, it's no problem, nor on non VPro Octane. The fault is aggravated in this case by selecting 'doublesize' for the XMMS player - they break differently but the base error is similar.

Since since then there are tons more Vpro users, what's the verdict and is there a simple fix? Or have I missed something blazingly obvious (and not the first time unfortunately, LOL!)

I was fighting a Linux problem (again!) , where all gtk+-1 apps were displaying all pixmaps as translucent. It may have looked cool to the eye candy junkies, but it made most programs unreadable. I have been messing around trying to fix it for some hours, then I remembered reading about a similar problem here.
It turns out imlib was rearing its ugly head by picking a RGBA 32bit visualid. It was then just a simple edit of imrc later and all things are better again. I also then found out I could disable xrender for the Xserver, but that is no fun...