Screaming Penguin

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.