20075 - RFE: Get rid of GTK+ on "native" Motif platforms

Status: VERIFIED WONTFIX

(SeaMonkey :: Build Config, enhancement, P3)

Description

[Roland Mainz]

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 !

Comment 1

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

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.

Comment 2

[Roland Mainz]

The current problem is that "configure" fails on Solaris 2.7 SPARC, and I'm not
familar with autoconf etc. Need help !!

Comment 3

[Dawn Endico]

changing severity to enhancement, changing component to build config,
and cc-ing cls, our resident autoconf guru.

Comment 4

[cls]

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.

Comment 5

[Roland Mainz]

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...

Comment 6

[cls]

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 [e-mail] 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.

Comment 7

[Roland Mainz]

> 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
[e-mail] 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 ;-(

Comment 8

[cls]

> 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.

Comment 9

[Roland Mainz]

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...

Comment 10

[Roland Mainz]

Q: Maybe we should change the "Summary" field to "fix Motif" ?

Comment 11

[cls]

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.

Comment 12

[Roland Mainz]

Created bug 22266 as a request to "fix Motif". Moved dependicy of bug 10001 (CDE
support) to bug 22266. IMHO this bug depends on 22266, added reference...

Q (to leger): What about changing this bug to "LATER" until Motif has been fixed
?

Comment 13

[leger]

Marking Verified.