[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-swt-dev] SWT & Native widgets
|
Hello,
I would just like to add my 2ยข worth of agreement to this discussion and
everything that has been said so far. Having been developing swing
interfaces for about five years now, some of them reasonably sophisticated,
I'm now in the process of porting some of my larger open source projects to
SWT. I am a huge fan (and now evangelist) of SWT - with the caveat that
people be developing windows applications. It would be nice not to have to
add this caveat when I talk to people. I think addressing all of the
issues the others have articulated so well, are a step in the right direction.
I would like to also ask, has there been any talk about, or has anyone else
thought about, the possibility of "packaging" SWT in a way that is less
intertwined with eclipse? It seems to me that a buzz is increasingly heard
amongst developers such as myself who are not interested in using a new
development environment, but are very eager to have a better alternative to
swing and awt. Unfortunately it seems like the boundaries are blurred
between SWT and eclipse. I almost never even bothered with SWT, because
downloading it and getting a quick, existing "hello world" type app to run
wasn't in the "few minute" timeframe that many of us take to check out
something new and decide whether or not it's worth further investigation.
Fortunately I persisted on this one, and now I look at virtually every
interface that I've worked on, past and present, with an eye for how it
could be better recast in SWT. (Mind you - I should point out that I'm not
one of those people with a strong dislike for swing. It's great for what it
is, and when you need a very rich API. But the truth is there are many
instances where you don't need such an API, and instead speed and native
look and feel take precedence.)
Anyway my point is, has anyone ever considered that SWT has begun to take
on a life of its own outside of the context of eclipse, and would benefit
from having its own "community," setting its own goals, with its own
releases, downloads, milestones, etc.? Of course I believe eclipse would
only stand to gain from further progress and adoption of SWT.
Thanks for listening,
Jim
At 04:06 PM 8/8/2002 -0700, snickell@xxxxxxxxxxxx wrote:
In the "star trek future" category it would be good to be able to
replace not only widgets, per se, but to (optionally) be able to specify
native implementations for all GUI code. So for example, to be able to
re-organize a particular dialogue, change the title of a preference
window, or display a smaller number of toolbar items. The results of
even the best widget-level-only native display systems rarely have a
truly native feel to them. Layout, alignment, and technique vary between
platforms, not just the particular widgets used.
A hard example from GNOME/GTK:
- Proper style dictates a different button ordering from the Windows
platform (see
http://usability.gnome.org/hig/draft_hig/windows.html@alert-windows).
Furthermore, use of "OK" buttons is discouraged in most instances, in
favour of verb-based buttons. Complementing this, preference pages are
supposed to be "instant apply" rather than requiring clicking of an "ok"
or "apply" button (I believe this is true of OS/X too).
A example from MacOS X:
- MacOS X has a completely different toolbar philosophy from Windows.
The Windows philosophy is to make the toolbar sufficiently complete that
most users will hardly ever need an item not in the toolbars. MacOS X
(and I'm leaning this way for GNOME too) uses the toolbar as a
convenient way to place shortcuts for the 5 or 6 most essential items. A
good Eclipse port for OS/X would need to do away with "Coolbars" (which
are wrong for GTK too, btw), use custom icons drawn in the OS/X
style/size, and provide a mechanism for reducing the number of displayed
toolbar items to the most important only.
I've seen two approaches to this problem. The first tries to build a
massive abstraction library that describes things like "preference page"
, "save alert", "shortcut item (i.e. toolbar item)", etc in supposedly
platform neutral terms. (or in a worse implementation, only describes
basic widgets, and then places them together the same way on all
platforms) Native backends are then called to format and display this
abstarct information. This is a backend-driven approach.
The other approach is to try to segment all interface code into
as-small-as-possible modules and then allow native objects to override
these. However, the native code is "in charge", treating the "actual
implemementation" as a useful backend library. This is a "native code
driven" approach. Becaues it puts the native code in charge, platforms
with odd requirements can usually do whatever they need to look native
(it just might take more work).
The first approach tends to require less native code in terms of LOC,
but in my experience the final result does not truly fit the host
platform, and the total development time is much higher (trying to make
a truly abstract library is really difficult, and then some new platform
does something you didn't expect and breaks evreything). Eclipse is
currently using the first approach. It has a certain theoretical
elegance, but I have yet to witness an instance of an application using
this approach that achieved good platform integration.
-Seth
Quoting Andre Weinand <weinand@xxxxxxx>:
>
> Yes, this is a big issue for the MacOS X port too:
>
> For example SWT provides a native progress bar if you know the range
>
> in advance.
> If you don't know this range JFace adds a "Pure Java" progress bar
> that is animated
> by a separate thread. On windows the "Pure Java" progress bar closely
> matches
> the native progress bar, on the Macintosh the native bar has a nice
> animated Aqua look
> and the "Pure Java" emulated bar still has the Windows look.
>
> Other examples from MacOS X:
> - JFace draws a separator line between the window's menu bar and the
>
> windows's content.
> However on MacOS X the menu bar is not located within the window.
>
> So there is a
> gratuitous separator at the top of a window.
> - the CTabFolder looks inappropriate in Aqua.
> - the pulldown menu of a toolbar item looks inappropriate in Aqua.
> - Eclipse "panes" with the gradient fill in the title area and the
> hard shadow around their border
> look OK on windows but naive on Aqua.
>
> There must be a way to replace "Pure Java" custom widgets by the
> appropriate native widgets.
>
> --andre
>
>
> >SWT (and other parts of eclipse) have a large number of widgets
> written
> >in "Pure Java" (the "common" directories). While technically
> speaking
> >these will run on any platform, many of them are effectively
> designed
> >for a specific platform: Windows. By way of example, the CTabFolder
> >widget matches Windows titlebars very nicely, but looks
> inappropriate in
> >GTK. Additionally, the GTK notebook widget could easily replace
> this
> >widget providing native functionality and looks (because GTK allows
> for
> >the packging of arbitrary widgets into tabs the pulldown menu and
> close
> >button can be added to provide identical features to the Java
> version).
> >
> >Because each platform has its own unique constraints, appropriate
> >widgets, and special widgets that other platforms do not have, it
> would
> >be useful to be able to take *any* widget in Eclipse and replace it
> with
> >a native version.
> >
> >There are two problems with this right now:
> >
> >1) The current infrastructure does not seem to allow for the common
> >directory to contain a set of all pure-java widgets, but then to
> allow
> >native versions to provide an implementation of those widgets as an
> >alternative. Widgets either have to be native-on-all-platforms or
> >native-on-no-platforms.
> >
> >2) SWT uses default visibility on a number of key fields and
> functions
> >in Composite, Widget, etc that would be necessary to subclass
> native
> >widgets from these. Effectively that means that the SWT
> infrastructure
> >can not be used to provide native replacements. Making these fields
> >protected would allow the definition of useful native versions of
> >widgets outside of org.eclipse.swt.widgets.
> >
> >Because GTK and Motif currently don't display a high degree of
> stylistic
> >unity it is easy to get away with having a bunch of pure-Java
> widgets
> >that "look like Windows". However, as a GTK style progressively
> evolves
> >(and is pushed forward by the GNOME-Human Interface guidelines) more
> and
> >more of these widgets will need GTK versions to look and feel
> right.
> >Also platforms such as MacOS/X will need a huge amount of native UI
> code
> >really pass them off as a "native" application. Everything from
> CoolBars
> >to CTabFolder to the way dialogues work will need to be customized
> to
> >create an application that integrates even tolerably well with Aqua.
> So
> >I think the principle of being able to replace any UI piece with a
> >native functional-equivalent is pretty important, and will become
> >increasingly important in the future.
> >
> >-Seth
> >_______________________________________________
> >platform-swt-dev mailing list
> >platform-swt-dev@xxxxxxxxxxx
> >http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
>
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
>
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
--
jim@xxxxxxxxx
Visit www.jbrix.org for:
+ SpeedJAVA jEdit Code Completion Plugin
+ Xybrix XML Application Framework
+ other great Open Source Software
