xpwidget awt peers
Christoph Toshok
having to worry about the issues of embedding a motif awt inside a gtk
application, I've started working on a set of xpwidget awt peers.
I'd say I'm about 40% done with the widget level code (images, for
example, haven't been worked on.) Testing it is a pain in the butt
since you can't link in the widget libs without pulling in most of
mozilla at the moment. this *is* due to change, however :)
I'd like to see this stuff MPL'ed checked into the mozilla cvs root. Is
there any interest in seeing this happen?
Chris
Aaron
wouldn't Swing solve this problem?
Aaron
Giao Nguyen
> I'm not familiar with gtk or motif (or X programming in general), but
> wouldn't Swing solve this problem?
swing doesn't give you native peers. you need native peers for awt.
Aaron
inside a gtk application..."). If this is the case, wouldn't the
conscious decision of the applet writer to move to Swing (a set of
cross-platform widgets) solve the problem?
Then again I could be misunderstanding and entirely wrong.
Aaron
Wesley Felter
> I thought Chris was talking about applets ("...embedding a motif awt
> inside a gtk application..."). If this is the case, wouldn't the
> conscious decision of the applet writer to move to Swing (a set of
> cross-platform widgets) solve the problem?
Swing is layered on top of AWT, so even if you use Swing, you still need an AWT implementation. Also, Mozilla needs to support applets that don't use Swing (I would assume that most of them don't).
Wesley Felter - we...@cs.utexas.edu
Ramiro Estrugo
>
> I thought Chris was talking about applets ("...embedding a motif awt
> inside a gtk application..."). If this is the case, wouldn't the
> conscious decision of the applet writer to move to Swing (a set of
> cross-platform widgets) solve the problem?
>
>
The fundamental problem, regardless of whether you use native, swing or
"mozilla xpwidgets" is that ultimately you are dependent on platform (1)
specific:
o An event loop / event dispatching
o A "widget" model
(1) Toolkit specific, actually.
-re
Mark Lin
Hi Chris.
I am with a group at Sun that is currently investigating ways of making
Mozilla work better with Java. One of our main concerns was figuring out
how
to embed Applets (which rely on an AWT implemented in Motif on Unix
platforms) into Mozilla which is currently using GTK.
We had four possible alternatives to this problem:
1) Use motif for the peer set implementation, and figure out a way to
embed
a motif window in a GTK window by using X hacks, such as XReparentWindow
(we
prototyped this, and got it to mostly work)
disadvantage: The UI's would clash and look strange, especially with
GTK
based themes
advantages: Easy to implement
2) Write a peer set in GTK
disadvantages: Writing a new peer set requires tons of maintence
problems and takes a lot of effort to write, test, and support
advantages: We end up supporting the JDK on linux much better with
GTK
because it won't rely on Motif anymore, and linux apps written in Java
won't
clash with the Gnome desktop. And most importantly, Java Applets would
integrate well and look nice with Mozilla
3) Write a peer set using the XPWidgets in Mozilla
disadvantages: Same as #2 above. Also, if we choose this path, we're
writing a peerset solely around the browser, not the platform. This was
the
path that Netscape took with their earlier 4.x AWT implementation, and
it
proved difficult to maintain and to keep up with changes in the current
JDK
versions. It became very buggy and difficult to do. I would not
recommend
doing this.
advantages: We end up writing a peerset which could work on
non-Unixes
such as the Mac and Windows, since the XPWidgets will be ported to these
platforms as well
4) Write a lightweight peerset implementation using the Swing library.
Yes,
you read that right :) We had this idea that since the only AWT
components
Swing relies on are Frame, Window, Dialog, we could use Swing as a
lightweight peer implementation for the AWT. I've written a prototype
proving that this could work and have implemented some AWT components in
this manner (Button, Checkbox, Frame, Label, List, Panel, TexArea, and
TextField). The only native peers we would have to implement would be
Frame,
Window, and Dialog.
disadvantages: Look and feel may look a little strange, but there is
some chance that a GTK look and feel may get written for Swing.
advantages: Users could switch to whatever Swing look-and-feel they
wanted (Metal, Motif, etc). Easy to write (since the code is all in
Java).
Easy to maintain (since the code is all in Java).
We finally decided that possibilities #2 and #4 were the best ideas.
However, the current situation is that, from what I understand, Mozilla
may
switch to a pure XLib toolkit implementation of XPWidget and GFX, so
that
would mean possibility #2 doesn't make sense anymore, and the "clashing"
UI
problems may be irrelevant, since Mozilla will likely clash with the
desktop
anyways since they are going with their own XUL based themes (likely to
be
based on CSS2 stylesheets?). So possibilities #4 and #1 seem to be the
best
choices right now, although it would be nice if the JDK on linux didn't
have
to rely on Motif.
What do you think?
It would be nice if we didn't duplicate efforts, since it sounds like
we're
both basically trying to solve the same problems.
-Mark
(mark...@eng.sun.com)
Ramiro Estrugo
you do. Mozilla has consciously decided to implement both chrome and
content using the layout engine. All widgets (except for menus - as of
now) will be rendered.
The look and feel for these widgets will be something nice - the Mozilla
look and feel! But, dont forget that tweaking this stuff is easy with
style sheets and XUL.
In other words, I dont think the clash between one toolkit and another
inside of mozilla (whether its GTK vs motif or "native" vs xptoolkit) is
an issue. Even though GTK themes are the sexiest thing in the galaxy,
they aren't really part of the equation. Since all interesting widgets
in Mozilla will be rendered, there are no themes to be (ab)used. In any
case, the look specified by the style sheet in content (like mozilla's
chrome) always wins.
Second and most important. The work Chris Blizzard is doing and I am
helping him with is not meant to REPLACE the current GTK Mozilla at all.
We are factoring out code that from our point of view makes a lot of
sense to be xlib only.
The "application" that we will build, release, qa, bless and support
over here at Netscape will be a GTK app. We cannot do away with
toolkits because of interesting features which are prerequisite: such as
drag and drop, clipboard, and others.
It is not our intention to reinvent the wheel and write yet another
toolkit. Quite the opposite actually. By writing xlib only code, we
open the doors to other toolkits as well. Already, the xlib only gfx
later in Mozilla (rendering) can be used with different toolkits (like
motif).
-re
> It would be nice if we didn't duplicate efforts, since it sounds like
> we're
> both basically trying to solve the same problems.
>
> -Mark
> (mark...@eng.sun.com)
>
> > In order to get japhar working with mozilla in a way that keeps me
> from
> > having to worry about the issues of embedding a motif awt inside a gtk
>
> > application, I've started working on a set of xpwidget awt peers.
> >
> > I'd say I'm about 40% done with the widget level code (images, for
> > example, haven't been worked on.) Testing it is a pain in the butt
> > since you can't link in the widget libs without pulling in most of
> > mozilla at the moment. this *is* due to change, however :)
> >
> > I'd like to see this stuff MPL'ed checked into the mozilla cvs root.
> Is
> > there any interest in seeing this happen?
> >
> > Chris
> >
--
-re
Bill Lipa
Mark Lin wrote:
> 4) Write a lightweight peerset implementation using the Swing library.
This idea sounds really elegant and cool, in that it could greatly reduce
compatibility headaches between the different AWT widgets (headaches that
are the bane of the applet developer). Basically, the more that can be done
with lightweight, Java widgets that are non-platform specific, the better.
Braden N. McDaniel
news:378F6FD3...@eng.sun.com...
>there is some chance that a GTK look and feel may get written for Swing.
Would that mean that GTK themes would automatically get applied to Java
app(let)s (using Swing, of course)? That would rule.
> problems may be irrelevant, since Mozilla will likely clash with the
> desktop
> anyways since they are going with their own XUL based themes (likely to
> be
> based on CSS2 stylesheets?).
Yes, the Mozilla UI will be largely XUL-CSS based. *But* CSS2 includes a
suite of keywords to identify system colors, and I believe this is to be
implemented in the first release of the browser. (It would be a huge mistake
not to do so.) So it's probably premature to say that Mozilla will clash
with the desktop. At least I sure hope it is.
> So possibilities #4 and #1 seem to be the
> best
> choices right now, although it would be nice if the JDK on linux didn't
> have
> to rely on Motif.
I don't think #1 is a good choice. If you want people to *use* Java under
Linux, it is important that it be easy to write applications that look
attractive and integrate well with the desktop.
A Motif-based widget set will not provide that.
But, given Sun's record to date, it's really questionable if they care much
whether Java gets used under Linux. And that's a shame. Because the paucity
of applets (let alone *useful* applets) on the Web suggests that Java should
be nurtured elsewhere.
> What do you think?
If a *quality* GTK l&f materializes for Swing, #4 is definitely the best
bet. In the absense of that, my vote's for #2.
--
Braden N. McDaniel
bra...@endoframe.com
<URI:http://www.endoframe.com>
Wesley Felter
> Mozilla has consciously decided to implement both chrome and
> content using the layout engine. All widgets (except for menus - as of
> now) will be rendered.
As a genuine Mac-owning UI nazi, this worries me a little. Will it be possible to use native widgets? Or at least some XUL widgets that look and feel exactly like native widgets? (Although I don't relish having to re-do Drawing Board in XUL...)
The reason why I ask is because I am not interesting in Mozilla looking the same on every platform; I would much rather that it look as much as possible like the platform on which it is running.
If I'm just being paranoid, go ahead and tell me.
Wesley Felter - we...@cs.utexas.edu
Greg Stark
Mark Lin <mar...@eng.sun.com> writes:
> We had four possible alternatives to this problem:
>
> 1) Use motif for the peer set implementation, and figure out a way to embed
> a motif window in a GTK window by using X hacks, such as XReparentWindow
>
> 2) Write a peer set in GTK
This would just be generically good karma, whether it's useful for Mozilla or
not. :) I'm not against Motif; I just want the choice. But I don't much see
the point in using Motif in Mozilla if Mozilla isn't going to be Motif itself
:)
> 3) Write a peer set using the XPWidgets in Mozilla
If the Mozilla people extract out XPWidgets as a module that doesn't depend on
the result of Mozilla then this might prove to be the most useful approach.
Java and Mozilla happen to have similar problems that stem from wanting to run
under multiple OS/Toolkits and if Mozilla happens to already have a solution
for you under development then by all means leverage it. That's why you bought
into the AOL/Sun/Netscape at all, wasn't it?
> 4) Write a lightweight peerset implementation using the Swing library.
Just for completeness there are at least two more alternatives. I don't
particularly think they're better choices for applet support under a Web
browser but they are worth keeping in mind.
Biss-AWT had* a "peerless" design that used a very thin Xlib/Windows/Mac
layer. I guess that would be fairly close to the idea of using Swing to render
the toolkit, I'm not exactly sure. (* I use the past tense only because I
haven't heard of any recent releases, but it may still be alive.)
Xtc was 100% pure Java implementation of the X protocol. On that you could
layer Swing or other pure Java toolkit and not have a any platform dependency
anywhere in the graphics engine at all. (Again I use the past tense but this
project may not be quite dead yet.)
Advantages: Can run applets on mac or windows under an X display (remotely or
to a local X server).
Disadvantage: I guess this doesn't solve the normal case for Windows and Mac
hosts.
greg
Makoto Kato
Mark Lin wrote:
> 2) Write a peer set in GTK
> disadvantages: Writing a new peer set requires tons of maintence
> problems and takes a lot of effort to write, test, and support
> advantages: We end up supporting the JDK on linux much better with
> GTK
> because it won't rely on Motif anymore, and linux apps written in Java
> won't
> clash with the Gnome desktop. And most importantly, Java Applets would
> integrate well and look nice with Mozilla
classpath is implementation of GTK. But, it isn't still complete...
--
Makoto Kato
mailto:m_k...@ga2.so-net.ne.jp
http://hp.vector.co.jp/authors/VA008030/
Justin Chapweske
netscape.public.mozilla.java.
We at Cyrus Intersoft have been working on a swing based peer
implementation that is about 95% there. If you are interested in details,
please talk to Mike Emmel (mem...@cyrus.net).
Later!
-Justin Chapweske, Cyrus Intersoft