1. I don't like to start a flame war like "Motif vs. GTK+" 2. We should think about replacing GTK+ with Motif on platforms where Motif is aavailable as "default" (like Solaris 2.x etc.) Why ? - GTK+ apps. causes much trouble with colors: for example, I cannot run Gimp,Mozilla or any other GTK+ app. at the same time as JAVA apps. - in this case all the text in the JAVA apps. is renders invisible (24bit visual, tested with JDK 1.1.8 and JDK 1.2.1_04). The same problem appears with Wind/U-apps. and some comercial products like SeqStar (a $60000 per cpu DNA sequencer software) - Smaller distributions: If Motif is already available on the target platform, why shipping an extra toolkit ? IMHO this only wastes space in the distribution tarballs. - ... Any comments/pro/contra ? Please no flames !
My understanding (which may be incorrect, since things may have changed in the past few months) is that the Motif build currently does not work, and therefore somebody needs to bring the motif widget and gfx code up to date.
The current problem is that "configure" fails on Solaris 2.7 SPARC, and I'm not familar with autoconf etc. Need help !!
changing severity to enhancement, changing component to build config, and cc-ing cls, our resident autoconf guru.
dbaron is correct; the motif is and has been busted for well over a month now (look at the motif build on the SeaMonkey-Ports tinderbox). Until this bustage is fixed, there is no point in making motif the default on select platforms. Putting the issue that only gtk+ is supported on unix platforms aside for a second, making a toolkit the default implies that to a certain degree, that building with that toolkit is supported. At the moment, no one appears to be supporting the motif build otherwise it would not have suffered from bitrot. If that support isn't there, then why should we move from a working build to a non-working one? If you still want to build using motif, configure using --enable-toolkit=motif. Marking as wontfix.
I think getting Motif up-to-date is more important that you think. 1. Performance with remote X: Currently Mozilla is suffering from bad performance if used with remote X (X terminals or ISDN/DSL lines). AFAIK this is at least 20%-30% a GTK+ issue as seem with other GTK+ apps ;-( 2. Porting: I have big problems with GTK+ and sparcv9 - it seems that I'm not able to produce _stable_ GTK+ sparcv9 (e.g. 64bit sparc) applications with Sun Workshop 5/6EA compilers. We need Motif for 64bit or we've to investigate why sparcv9 GTK+ apps are broken (BTW: Does the DEC Alpha port work stable ?) 3. Distribution size: As I said in my first posting here: Why wasting some MBs in the distribution archive with statically linked GTK+ when Motif is available on the target platform... ? 4. Problems with Solaris: The color problem is still here...
I never said that getting the Motif build upto date was not important. I just said that it wouldn't be turn on by default until it at least builds. Wrt your points, 1) I don't believe the problem displaying mozilla remotely is solely a gtk+ problem. Last I heard, it was a problem in the classic build (motif based) as well as xlib builds. 2) Does the gtk+ development team know about the problems with sparcv9? Do you have the same problems if using gcc? Afaik, the linux alpha build varies in stability but you might want to ask firstname.lastname@example.org for more details. 3) This is just a rehash of the discussion made when gtk+ was originally choosen a year ago. Build size is neglible when compared to maintenance costs. If size were the main concern, then we should just use xlib and drop all other toolkits. 4) Again, this is a issue for the gtk+ development team. At least one of the gimp/gtk+ faqs mentions colormaps.
> 1) I don't believe the problem displaying mozilla remotely is solely a gtk+ > problem. When I log-in remotely on a Sun in our cluster the resposibility ("speed") of the desktop is much better if I shut down all GTK+ apps. I asked the author of an ICQ-App to fix this, and his forwarded my request to the GTK+ people. Working locally on the same machine isn't a problem. Seems that GTK+ needs some more optimisations for remote X... ---- > 2) Does the gtk+ development team know about the problems with sparcv9? IMHO yes - I wrote them two mails in the last half year but I didn't get any response ;-( > Do you have the same problems if using gcc? gcc sparcv9 doesn't work properly yet. I can hack-up a compiler, but it compiles rubbish for larger projects... We're forced to use the Sun Workshop compilers, but currently the resulting apps are instable if they're using GTK+. Running them (older freeamp versions for example) without GTK+ works stable, therefore I think it IS a problem with GTK+. ---- > Afaik, the linux alpha build varies in stability but you might want to ask email@example.com for more details. > 3) This is just a rehash of the discussion made when gtk+ was originally choosen > a year ago. Any URL of this discussion ? ---- > Build size is neglible when compared to maintenance costs. If size > were the main concern, then we should just use xlib and drop all other toolkits. =:-) ---- > 4) Again, this is a issue for the gtk+ development team. At least one of the gimp/gtk+ faqs mentions colormaps. AFAIK the FAQ handels 8bit/256color problems, I didn't found any comments about "wrong colors on 24bit visuals". It's very frustrating. My users have to log-out and relogin after using Gimp/Mozilla if they want to use a JAVA-/WindU_based app. ;-( But this may be a Solaris-only problem... Solaris 2.6 doesn't have this problem, but 2.8 beta has it, too ;-(
> Any URL of this discussion ? None that immediately pop to mind. news.mozilla.org does not expire articles so you could look for posts in m.builds & m.netlib around Oct 31, 1998. Also, I'm almost certain a bit of the discussion was held offline at netscape. > It's very frustrating. My users have to log-out and relogin after using > Gimp/Mozilla if they want to use a JAVA-/WindU_based app. ;-( > But this may be a Solaris-only problem... Solaris 2.6 doesn't have this > problem, but 2.8 beta has it, too ;-( I have a Solaris/x86 2.7 box that I'm using as a tinderbox for Mozilla. It's running with a 24 bit display and has java 1.1.6 installed. Mozilla displays briefly while the tinderbox is running its tests and I have been able to run Hotjava w/o any problems. ICQ java runs as well but appears to have a refresh problem that I believe is unrelated to gtk. A friend of mine used to have colormap problems related to java on his Solaris/sparc 2.5 box (8bpp) but I do not know if he was using any gtk apps at the time. At no point did he have to relogin to fix his colormap problems though so I suspect there's something else at play here.
Another issue: CDE support (drag&drop etc.) depends on Motif. CDE filetyping seems to be independent from Motif, other things like drop areas and drag points may only work with Motif widgets...
Q: Maybe we should change the "Summary" field to "fix Motif" ?
IMHO, you should open a new bug for fixing the motif build as fixing the motif build and making it the default build choice are two separate issues.