Let's build some new stuff!
Joel Webber
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.
bg
supporting multiple stylesheets depending on the media? I know that in
traditional web design it was a matter of specifying a stylesheet
specifically for printed media, for example.
<LINK rel="stylesheet" type"text/css" href="print.css" media="print">
I don't know how the game might change with a gwt app, but I don't
suppose it would be too different.
Jason Essington
On Jan 8, 2007, at 12:16 PM, Joel Webber wrote:
> 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.
>
I've got working samples of some of this stuff already. Unfortunately
some of it is no where near pretty enough for inclusion in GWT as is,
but I would certainly not be too afraid of tossing it on the table
for discussion.
> ---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.
>
> 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
Got one of these. but it could probably be redesigned, I should look
at it again.
>
> 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.
Sure, RoundedPanel (using CSS rather than images). This one has been
posted to the list. I also use that panel along with some Effects
(see below) to create a "clamshell widget"
> 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).
Got one of these! not only does it work with the typical add remove
buttons, but it also supports multiple selection, Drag N Drop(see
below), Double Click moving. the one thing it doesn't really support
yet is Drag reorder. This guy works (on all platforms), but is pretty
ugly, and could use a bit of clean up.
And if I remember correctly, this guy doesn't use the listbox
element, it uses divs so it supports arbitrary widgets as list items.
> ---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.
I've begun some work on one of these.
It has some base interfaces:
Effect
EffectListener
SourcesEffectEvents
then there is an AbstractEffect that handles some of the timing
issues for an effect.
a WidgetEffect that extends AbstractEffect as a base class for
effects that manipulate widgets.
Then of course some implementations:
ScaleEffect
BlindEffect
MoveEffect
ShakeEffect
and some support classes:
EffectListenerAdapter
EffectCommandListener (for chaining effects)
etc.
I could pretty easily get this packaged up and placed somewhere so we
can compare notes with for instance kelly's effect implementation or
any other ones that are available. I've already run into some nasty
little gotchas here, so would be happy to take part in this discussion.
probably best to start a new thread for this one.
> 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.
Got one of these too:
Same sort of deal, it has base interfaces:
DragEvent
Draggable
DragListener
Droppable
And some implementation classes. This one has some really ugly
implementation details that could sure use some vetting in a
different thread.
Again, I'm not too afraid of tossing my existing implementations out
for discussion or for comparison with others who may have started
some of the same things.
-jason
>
Robert Hanson
favor any one over the others, although a good DnD is a big deal I
think.
> Color Palette:
I have a prototype picker at the URL below that embodies what I would
like to see in a picker. It uses buttons, so there is no external
image requirement. If you have seen the FF ColorZilla plugin, it
looks pretty similar. When it is complete it will also support the
same custom palettes that Gimp does loaded via external palette files.
[ColorPicker prototype]
http://gwt-widget.sourceforge.net/prototype/colorpicker/index.html
[Gimp palette examples]
http://www.iosart.com/firefox/colorzilla/palettes.html
> Inline Text Edit
The GWT-WL has this. Adam Tacy wrote it many months ago. I believe
that it supports both TextBox and TextArea editing. It was built to
look like the editable labels on the Flickr site. I can't think of
what features you might want for this.
> Progress bar & busy indicators
The GWT-WL has a progress bar written by Bjarne Matzen. It allows for
flexible styling with CSS, which I think is a must-have feature for
this widget. It also supports displaying time remaining and some
arbitrary text. The constructor lets you specify the number of bars
in the widget. Over time you alter the percent complete and it colors
the appropriate number of bars.
ProgressBar progressBar = new ProgressBar(20 ,ProgressBar.SHOW_TIME_REMAINING);
progressBar.setProgress(50);
I am not sure if this is the perfect progress bar, but I think it
would be a good reference. I think there are also a few other ones
out there, but none come to mind.
> Date & Time Pickers
The GWT-WL has what I think is a pretty good start for a calendar.
There is a cal panel and cal engine. On top of that it should be easy
to build any sort of date picker. Allows for altering the day
abbreviations, first day of the week, month names, supports date
clicks, can hold event data, and highlights days with events. It
should also be pretty easy to build a date range picker, like the one
in Google Analytics.
What seemed to work well was separating the cal engine and panel from
any buttons or other controls.
> Good default CSS
Yes, yes, yes!
> Vector Graphics: This is a thorny problem.
This one would also require that namespace support be added to GWT. I
have a small SVG implementation that I put together over the summer,
and I remember having to build an alternate DOM object. I think that
this is a crazy big project to get it right, but definately worth it.
> Tag clouds
Where does the data come from? Do you envision that it would support
the popular services, or would you have to roll your own servlet
implementation to feed it?
> Slideshow: This might be a bit frivolous
I am not a big fan of this one, but if it gets built, I am sure that
it will be used.
Rob
Bruce Johnson
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.
Maybe it could just be a variation on the existing Image class by adding ctors and methods:
public Image(String url, int left, int top, int clipWidth, int clipHeight)
public void setClipWidth(int clipWidthInPixels)
public void setClipHeight(int clipHeightInPixels)
...
There isn't necessarily a need to enforce each sub-image to be of uniform dimension. If it became useful to do so, then we could later introduce ImageStrip written in terms of the Image clipping functions that does the simple computations for you:
class ImageStrip extends Widget {
public ImageStrip(Image masterImage, int subImageWidth, int subImageHeight)
public int getImageCount()
public Image getImage(int subImageIndex) {
return new Image(masterImage, subImageIndex * subImageWidth, 0, subImageWidth, subImageHeight);
}
}
Stuff like that.
This should be able to interact with the Toolbar and ImageButton widgets.
-- Bruce
Mark Bakker
http://code.google.com/p/gwt-svg/
as pointed out by Joel SVG and VML is probably not enough to get a full implementation of a Vector API. I started to do some research to the javascript flash API, as reference I use;
http://livedocs.macromedia.com/flash/8/main/wwhelp/wwhimpl/js/html/wwhelp.htm?href=00004358.html
Until now I still have no working POC for the flash implementation. Hopefully next weekend this will change.
Robert addressed that SVG implementation needs namespace support. I came to the same conclusion.
Fred
On Jan 8, 12:16 pm, "Joel Webber" <j...@google.com> wrote:
> 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.
Thought I'd mention my recently uploaded drag-and-drop implementation:
http://code.google.com/p/gwt-dnd/
There's a link to working examples so you can play with the
implementation in your browser. The library has classic drag-and-drop
support, but also the ability to move (drag) within an AbsolutePanel,
either freely or constrained by a grid. This functionality is
controlled by different `DropContoller`s associated with the different
drop targets.
Feedback is welcome and appreciated.
Fred
Emily Crutcher
Jason Essington
causes it to go to the trash bin on drop.
Seems to work fine in firefox though.
-jason
David Evans
Really cool tho!
Bruce Johnson
Scott Blum
Ok, but seriously, this is a very cool demo!
Fred
If the gwt-dnd code is up to snuff and the team is interested, I'd like
to eventually contribute this to the GWT code base. I realize there's a
lot that needs to happen before it's ready for that step. So, any
specific feedback on the API, especially from google-web-toolkit
project owners/members would be appreciated.
As for Safari, anyone know a way I can test in that environment without
obtaining an actual Mac? Applers should be able to drag-and-drop too!
Thanks
Fred
bg
I believe Konqueror is based off the same HTML rendering and JS
implementation as Safari, so if you develop on a linux box give that a
shot. Or if you have a spare computer laying around throw Kubuntu on it
and give it a whirl....
bg
Fred
I tried the latest Kubuntu release. However, it looks like not even the
GWT Ktichen Sink will run in Konqueror at this time :-(
Thanks for the suggestion, though.
Fred
On Jan 25, 10:50 am, "bg" <bgour...@gmail.com> wrote:
> Fred,
>
> I believeKonqueroris based off the same HTML rendering and JS
Joel Webber
Thanks,
joel.
bg
not use Safari specific code when it identifies Konqueror as the
browser?
John Tamplin
Sorry to go off topic for a moment but could this be because GWT does
not use Safari specific code when it identifies Konqueror as the
browser?
--
John A. Tamplin
Software Engineer, Google
Fred
On Jan 2, 11:19 am, "Emily Crutcher" <e...@google.com> wrote:
> Events are going to be interesting to retrofit. We've known we've boxed
> ourselves in a corner with our event model for a while, fixing it is a
> harder problem. One solution we have explored is to introduce "Handler"
> event classes to supersede the listener classes, check out FormHandler as an
> example. The handler model creates a event object to submit to the user,
> which allows us to add more fields to an event without breaking the
> currently existing code.
While revamping the event handling, what are the thoughts on allowing
more than one EventListener to be registered with an element? Are the
problems this would pose? The idea would be that where today we have:
DOM.setEventListener(Element elem, EventListener listener)
we would instead have (deprecating the old method):
DOM.addEventListener(Element elem, EventListener listener)
DOM.removeEventListener(Element elem, EventListener listener)
I'd like to have the multiple EventListener capability so I can for
example add drag-and-drop functionality to arbitrary existing widgets,
without requiring that the draggable widgets implement
SourcesMouseEvents. I also don't want to replace (steal) the widget's
own EventListener in case the widget wants to sink its own events.
Event previews aren't a good fit either for performance reasons and
because I'd have to try to manually figure out which widget should be
affected based on the mouse coordinates. That's the browser's job.
Thanks
Fred
charlie...@gmail.com
On Jan 24, 1:43 pm, "Fred" <fre...@gmail.com> wrote:
> On Jan 8, 12:16 pm, "Joel Webber" <j...@google.com> wrote:
>
> > 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.Thought I'd mention my recently uploaded drag-and-drop implementation:
charlie...@gmail.com
Most important, if I had to vote:
Data Binding
Consistent Selectability
Image Strip
Toolbar
DnD
Effects
Progress-Busy
Date-Time
> easier to build printing support ...
>
> read more »
Bruce
(http://groups.google.com/group/Google-Web-Toolkit-Contributors/
browse_thread/thread/e76ac5454546fc72). Let me know if you have any
feedback.
-- Bruce
On Jan 28, 4:01 am, "charlie.coll...@gmail.com"
> > Maybe this needs to be in code, or maybe default CSS...
>
> read more »
dgirard
What about adding the Office 2007 "Ribbon". I think it will be a cool
widget in the near future :
http://ajaxian.com/archives/implementation-of-office-2007-ribbon-with-
ajax
http://weblogs.java.net/blog/kirillcool/archive/2006/09/
office_2007_ui.html
http://blogs.msdn.com/jensenh/archive/2005/09/14/467126.aspx
Didier
charlie...@gmail.com
image names as well (which may be tricky because the name is in the
annotation, I am not sure about the consequences there).
Overall the work/approach thus far looks great. I especially like how
in addition to performance issues this would also help address the
bouncy startup. And I think having the 1x1 clear.cache.gif file could
be good in many scenarios, not really a detriment at all.
> > > Good default CSS: Let's just...
>
> read more »