Screaming Penguin - Source Does Matter

From the GWT-contrib mailing list. Looks like much of what all of us either have one off implementations of, or have been thinking about rolling, is already on the "list" for GWT.

Of particular note, lots of stuff on the "list" has already been implemented in third party circles, such as: http://code.google.com/p/gwt-dnd/

From Joel Webber on the contrib list
--------------------------------------------

All,

We've had a lot of ideas for new widgets and libraries banging around in our
heads for a while, and I think it's about time we started really building
out the UI library. To this end, I'd like to propose a set of potential
Widgets and simple frameworks that will give GWT apps much more leverage in
building good interfaces. The set below is really just a brainstorm, and
I'd love to get everyone's feedback on which ones they think are most
important, not important, missing, and so forth. This will probably end up
being a really long thread, but I'm sure it'll be worth it.

joel.

---Simple Widgets---
These are relatively simple widgets that would be convenient for many
developers. They all have minimal interaction with other widgets, and
shouldn't be hard to implement.

Color Palette: This is one that everyone seems to have, though I haven't
seen them used all that often in real apps. But it's pretty easy to do.

Inline Text Edit: For wont of a better name, anyway. Imagine a label that,
when clicked on, becomes editable. I think that some apps could benefit from
something like this, and it would save the trouble of building it by hand.e

Slideshow: This might be a bit frivolous, but people do build lots of pages
that show sets of images, so it might be useful. The idea is that you would
specify a set of images to be shown in some sequence. It would be possible
to stop, start, move back and forward, and change the speed. It should
probably be capable of doing nice cross-fades and such, possibly in
conjunction with the effects framework below.

Decorated panels: A set of SimplePanels that provide some sort of styled
decoration around an existing Widget. RoundedPanel is the most common
example, but there may be others that would be useful as well.

Collapser (i.e. simple one-item tree): A lot of complex forms use the idea
of a collapsible widget that can be opened and closed by clicking on a
little arrow.

Progress bar & busy indicators: A progress bar is pretty obvious, and a busy
indicator could be something as simple as a popup image that uses an
animated gif.

Tag clouds: What web2.0 app would be complete without a tag cloud?

Value Spinner: A text box with a number in it that has up/down buttons
(usually to the right) to adjust it. This is a little bit old-school UI, but
there are places where they're useful.

Link List: How many times have you stuck a bunch of links in a
VerticalPanel? Perhaps we should just make a simple Widget out of this.

Sliders: Everybody loves sliders: horizontal, vertical, smooth, stepped,
with & without stops. Kind of like Waffle House hashbrowns (sorry to
non-southerners who don't get that reference).

Dueling Listboxes: I don't know what everyone else calls them, but I like
this name. Basically, two list boxes that allow you to move a set of items
between them using add/remove buttons (usually placed between the list
boxes).

Image map: Sure, you could implement this by hand, but why not take
advantage of the browser's built-in support, along with tools for generating
them?

Image Button: I like using the browser's built-in buttons most of the time,
but sometimes you want a very specific effect you just can't get without
custom images.

Image Strip (Optimization): This one's a little weird, but bear with me
here. Loading lots of little images takes a long time -- all those HTTP
requests. Those of us old enough to remember writing Windows apps in C
probably remember using image strips for toolbars. It's a pretty simple
concept: use a single, long, image that has a bunch of equally-sized
sub-images that can be rendered separately. We can get the same effect in
the browser using CSS tricks. This will be generally much more efficient, as
it only requires a single HTTP request for the image strip, as opposed to a
lot of little ones. This should be able to interact with the Toolbar and
ImageButton widgets.

Toolbar: Lots of apps use standard Windows/Mac-style toolbars. Most rich
text editing widgets, for example, use toolbars to control text editing.
This widget should be able to use the Image Strip as an optimization. It
should also provide simple methods for grouping widgets, handling mutually
exclusive states, etc.

---Complex Widgets---

Vector Graphics: This is a thorny problem. We really need a solid approach
that will solve all of the relevant problems and work on every modern
browser. There are a few different approaches that bear exploring, but no
single solution will work on all browsers. These are the issues as I see
them on each:
- IE: supports VML, but not SVG or Canvas. No, the Google IECanvas library
doesn't count, as it has serious performance issues.
- Firefox: supports SVG and Canvas, but its SVG support can be pretty
freaking slow at times.
- Safari: supports Canvas only. SVG support should arrive sometime between
now and the time the universe dies a heat death.
- Opera: v9 supports SVG (Canvas, I'm not sure about). Reasonably fast. v8
supports pretty much nothing.
I could live without Opera8 as long as we can support v9. This might lead us
to consider VML on IE, Canvas on Safari, and SVG on Firefox and Mozilla.
They have pretty much compatible feature sets. Except for one nasty little
problem: Canvas doesn't support text. At all. You could try and overlay text
using the DOM on top of Canvas, but you lose z-ordering, affine transforms,
and probably a lot of performance. This leads me to consider Flash as an
option. It would be a pain, but if we can find a reasonably efficient way of
communicating between Flash and Javascript, we could write a library that
pumps display lists into Flash. It just so happens that Flash has a really
efficient renderer as well, but this is going to require a bit of research
to prove that it will work.

Rich Text: This one is a no-brainer (that it needs to be implemented, not
necessarily the implementation itself). A couple of people have started
implementations, and it shouldn't be too difficult to finish one. The big
question is Safari, which only 'sort of' supports rich text editing. We need
to be sure to find a way to support it so that applications can respond
reasonably to the available feature set.

Fast Table: The existing HTMLTable/Grid/FlexTable are flexible and (IMHO)
pretty easy to use, but there are cases where you don't need all that
flexibility, but you want it to run really fast. Emily is currently working
on extensions to HTMLTable that will make it possible to populate them very
quickly in certain cases.

Splitter Panels: A lot of traditional desktop apps use 'splitters' to
separate segments of the UI (you know, those panels that have the draggy
thing between their children). This is actually pretty tricky to implement
in such a way that it works generally, but I think it can be done.

ComboBox (not just a drop-down): It's interesting that the term 'combo box'
has come to refer to a simple drop-down box, whereas the original 'combo'
has been lost on the web (it should refer to an editable text box with a set
of options that show up in the drop-down area).
- It would be nice to provide an auto-complete option.
- It would be even nicer if that auto-complete option played nice with a
model interface that allowed the developer to swap out to an RPC backend
(for server-side autocomplete)

Date & Time Pickers: These are really important for a wide variety of apps,
and there are a lot of implementations out there we can use as examples. One
thing we do want to be sure of, though, is that they will play nice with
whatever date i18n framework we come up with (the browser is currently
pretty lacking in this respect).

---General Frameworks---

Effects: GWT needs a native 'effects' library in the spirit of scriptaculous
(preferably one whose name is easier to spell). The existing wrappers are
pretty cool, but they force you to include a large amount of unnecessary
javascript that slows your page load, and can't take advantage of Java
optimizations and deadstripping. Much like scriptaculous, however, it should
be orthogonal to widgets, and not require direct support from widgets
themselves.

Drag & Drop: It shouldn't be too difficult to build a library that
simplifies the process of allowing users to 'drag' stuff from one widget to
another. It'll take some time to hash out what this actually means on the
group, which we should probably do in another thread.

Custom tool-tips: UIObject.setTitle() is nice for really simple tooltips,
but it might be good to allow more complex ones to be built. This should be
relatively easy with PopupPanel.

Data Binding and Form Validation: I won't detail these here, since Emily's
already working on them and they are being discussed on the list right now,
but I wanted to reference them here for completeness.

---Other---

Good default CSS: Let's just say it -- our default CSS is ugly. Every time I
see another site that uses my hideous menu styling, I cringe a little. We
need to provide some good default CSS for the built-in widgets to make
everyone's life a bit more aesthetically pleasing!

Consistent selectability: I'm not sure how best to handle this, but it would
be great if things that shouldn't be user-selectable are not, by default.
It's pretty ugly to allow your entire application to be selectable, causing
the whole thing to flash weirdly when the user accidentally click-drags.
Maybe this needs to be in code, or maybe default CSS would be sufficient.

Ubiquitous keyboard support: The only widget I know of that doesn't support
the keyboard well out-of-the-box is the MenuBar (though maybe I've forgotten
something). We need to get this fixed, and make sure that new widgets for
which it makes sense also have good keyboard support.

TabBar Needs Widgets: Minor issue -- the TabBar needs to be capable of
having other widgets attached to it, both on the bar and in the tabs
themselves.

Printing support: This is more of an open question -- how can we make it
easier to build printing support into GWT apps? It's tempting to say that
it's entirely application-dependent (which it may be), but if we can think
of a good way to make it easier, it would be a big win.