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
...
Regarding Printing support, is there much more we could do besides 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.
> 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.
I think that all of the ones you listed are important. I hesitate to 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.
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.
> 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.
> 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.
This one shouldn't be overlooked because it could save so many HTTP round trips which are major performance killers in app speed.
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.
That's one nice thing about just tweaking Image: it should "work by default"(tm)
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;
> > 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.
> This one shouldn't be overlooked because it could save so many HTTP round > trips which are major performance killers in app speed.
> 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.
> That's one nice thing about just tweaking Image: it should "work by > default"(tm)
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.
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.
> 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.
> 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
-- "There are only 10 types of people in the world: Those who understand binary, and those who don't"
> 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.
> 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.
> That's pretty cool, but on Safari, any attempt to drag a widget > causes it to go to the trash bin on drop.
> Seems to work fine in firefox though.
> -jason
> On Jan 24, 2007, at 11:43 AM, Fred 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.
> > 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.
> On Jan 24, 1:50 pm, Jason Essington <jason.essing...@gmail.com> wrote: > > That's pretty cool, but on Safari, any attempt to drag a widget > > causes it to go to the trash bin on drop.
> > Seems to work fine in firefox though.
> > -jason
> > On Jan 24, 2007, at 11:43 AM, Fred 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.
> > > 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.
Your demo is awesome, but it lacks a way to get things back out of the trash can. I took every widget from every tab and put them all in the trash can. But now I have no more widgets to play with and am very sad!
Ok, but seriously, this is a very cool demo!
On 1/24/07, Emily Crutcher <e...@google.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.
> > 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.
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
On Jan 24, 3:17 pm, "Scott Blum" <sco...@google.com> wrote:
> Your demo is awesome, but it lacks a way to get things back out of the trash > can. I took every widget from every tab and put them all in the trash can. > But now I have no more widgets to play with and am very sad!
> Ok, but seriously, this is a very cool demo!
> On 1/24/07, Emily Crutcher <e...@google.com> wrote:
> > I haven't looked yet at your code, but your demo is really awesome!
> > > 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.
> > > 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.
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
On Jan 25, 11:35 am, "Fred" <fre...@gmail.com> wrote:
> 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
> On Jan 24, 3:17 pm, "Scott Blum" <sco...@google.com> wrote:
> > Your demo is awesome, but it lacks a way to get things back out of the trash > > can. I took every widget from every tab and put them all in the trash can. > > But now I have no more widgets to play with and am very sad!
> > Ok, but seriously, this is a very cool demo!
> > On 1/24/07, Emily Crutcher <e...@google.com> wrote:
> > > I haven't looked yet at your code, but your demo is really awesome!
> > > > 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.
> > > > 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.
> I believeKonqueroris 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
> On Jan 25, 11:35 am, "Fred" <fre...@gmail.com> wrote:
> > Wow! Thanks everyone for the positive feedback.
> > 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
> > On Jan 24, 3:17 pm, "Scott Blum" <sco...@google.com> wrote:
> > > Your demo is awesome, but it lacks a way to get things back out of the trash > > > can. I took every widget from every tab and put them all in the trash can. > > > But now I have no more widgets to play with and am very sad!
> > > Ok, but seriously, this is a very cool demo!
> > > On 1/24/07, Emily Crutcher <e...@google.com> wrote:
> > > > I haven't looked yet at your code, but your demo is really awesome!
> > > > On 1/24/07, 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.
> > > > > 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.
> 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 > > 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
> > On Jan 25, 11:35 am, "Fred" <fre...@gmail.com> wrote:
> > > Wow! Thanks everyone for the positive feedback.
> > > 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
> > > On Jan 24, 3:17 pm, "Scott Blum" <sco...@google.com> wrote:
> > > > Your demo is awesome, but it lacks a way to get things back out of > the trash > > > > can. I took every widget from every tab and put them all in the > trash can. > > > > But now I have no more widgets to play with and am very sad!
> > > > Ok, but seriously, this is a very cool demo!
> > > > On 1/24/07, Emily Crutcher <e...@google.com> wrote:
> > > > > I haven't looked yet at your code, but your demo is really > awesome!
> > > > > On 1/24/07, 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.
> > > > > > 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.
> 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 > > 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
> > On Jan 25, 11:35 am, "Fred" <fre...@gmail.com> wrote:
> > > Wow! Thanks everyone for the positive feedback.
> > > 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
> > > On Jan 24, 3:17 pm, "Scott Blum" <sco...@google.com> wrote:
> > > > Your demo is awesome, but it lacks a way to get things back out of the trash > > > > can. I took every widget from every tab and put them all in the trash can. > > > > But now I have no more widgets to play with and am very sad!
> > > > Ok, but seriously, this is a very cool demo!
> > > > On 1/24/07, Emily Crutcher <e...@google.com> wrote:
> > > > > I haven't looked yet at your code, but your demo is really awesome!
> > > > > On 1/24/07, 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.
> > > > > > 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.
> 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?
Basically many of the improvements Apple made since WebKit was forked from KHTML have not made it back into KHTML. That leaves KHTML with a number of problems which prevent GWT from working. Kelly or Joel could give details, but my understanding is there is no suitable workaround to these problems.
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.
> 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.
> 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
> On Jan 8, 2:16 pm, "Joel Webber" <j...@google.com> 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.
> > ---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.
Very slick. Though I do like Sandy's idea of using Constants for the 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.
On Jan 28, 12:14 pm, "Bruce" <gwt.team.br...@gmail.com> wrote:
> > On Jan 8, 2:16 pm, "Joel Webber" <j...@google.com> 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.
> > > ---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
