New API: FastTree

[Emily Crutcher]

Fast Tree is a new Tree API. It breaks the old Tree API in a couple of different ways, outlined below. It is 3-10 times faster then the old Tree as well. 

Wiki, with links to demo and live code:
http://code.google.com/p/google-web-toolkit-incubator/wiki/FastTree

Main changes:

• FastTreeItem no longer uses image widgets, uses css background images instead.
• TreeListeners functionality  has been replaced with overridable methods from FastTreeItem  such  as  onSelected(), ensureChildren(), and  beforeOpen()     
  
• Selection now highlights horizontally using a selection bar. Users can customize how the bar highlights their items. 
• Added HasFastTreeItems  interface for convenience when adding items to the tree or the tree items
• All styles delegated to CSS to allow user customization of tree.
  
• Uses StyleInjector library to provide default stylesheet for FastTree
  

--
"There are only 10 types of people in the world: Those who understand binary, and those who don't"

[Pavel]

Emily Crutcher wrote:
>
> * All styles delegated to CSS to allow user customization of tree.
>

It would've been nice if CSS customization allowed dotted lines (a
loaded topic)?
http://code.google.com/p/google-web-toolkit/issues/detail?id=543#c20

Pavel

[Emily Crutcher]

The primary purpose of the new FastTree is to be, well, fast. It's secondary purpose is to expose more tree behaviors to the user to create more interactive trees.   All the styling is done via css style sheets to maximize what flexibility we have left.

So to support enhancements such as dotted lines, we can add more behavior hooks, but could not add DOM changes which slow down the tree. Creating trees with lines is also not a high priority for me,  but if someone else would like to work on it with those constraints understood, I'd be happy to lend a hand.

       Cheers,

               Emily

[Pavel]

Well, the name of the class communicates it's purpose perfectly. With
the proposed API changes I was hoping to solve some fundamental
performance issues of default GWT tree, thus making it fast and allowing
some wiggle room for nice features such as optional (CSSable) dotted lines.

I guess I just need to come up with a prototype.

Pavel

Emily Crutcher wrote:
> The primary purpose of the new FastTree is to be, well, fast. It's
> secondary purpose is to expose more tree behaviors to the user to
> create more interactive trees. All the styling is done via css style
> sheets to maximize what flexibility we have left.
>
> So to support enhancements such as dotted lines, we can add more
> behavior hooks, but could not add DOM changes which slow down the
> tree. Creating trees with lines is also not a high priority for me,
> but if someone else would like to work on it with those constraints
> understood, I'd be happy to lend a hand.
>
> Cheers,
>
> Emily
>
>
>
>
> On Jan 15, 2008 4:51 PM, Pavel <pav...@gmail.com

[Sam Gross]

Hi Emily,

Nice work on the Fast Tree.  It looks good and is responds quickly on all browsers.  I was impressed by the speed with which a node with 500+ children expanded on IE6.

I have a few suggestions and questions about the behavior of the tree: 

• Expanding and collapsing nodes causes the browser to scroll so that the highlighted node is in view.  To reproduce this behavior, highlight and expand child0 in the lazy tree.  Scroll down so that child0 is off the top of the screen and expand one of its children.  The view snaps up so that child0 is at the top of the screen.

• Is it possible to prevent text selection when pressing on the '+' or '-' buttons?  Rapidly opening and closing a node is sometimes interpreted as a double-click and highlights the node's text, which is a bit unexpected.

• Would it be possible to implement double-click to expand behavior on nodes? Trees on Windows and Mac have this behavior, and I think users are likely to expect it.

I noticed a few styling issues: 

• Firefox puts a box around the selected tree item (see attached image).  Can it be removed?
• The selection bar expands beyond the width of the tree in browsers using the W3C box-model.

-Sam

[Emily Crutcher]

Thank you for your great feedback! Comments inline below.

On Jan 23, 2008 4:02 AM, Sam Gross <cole...@gmail.com> wrote:

Hi Emily,

Nice work on the Fast Tree.  It looks good and is responds quickly on all browsers.  I was impressed by the speed with which a node with 500+ children expanded on IE6.

I have a few suggestions and questions about the behavior of the tree: 

• Expanding and collapsing nodes causes the browser to scroll so that the highlighted node is in view.  To reproduce this behavior, highlight and expand child0 in the lazy tree.  Scroll down so that child0 is off the top of the screen and expand one of its children.  The view snaps up so that child0 is at the top of the screen.

Yep, that will be fixed.

 

• Is it possible to prevent text selection when pressing on the '+' or '-' buttons?  Rapidly opening and closing a node is sometimes interpreted as a double-click and highlights the node's text, which is a bit unexpected.

Yep, that can be mostly fixed. Mozilla provides a style, with IE its an event, so in IE we will only render them unelectable lazily.
 

• Would it be possible to implement double-click to expand behavior on nodes? Trees on Windows and Mac have this behavior, and I think users are likely to expect it.

Can you elaborate a bit more on this one? I don't think I quite understand.
 

I noticed a few styling issues: 

• Firefox puts a box around the selected tree item (see attached image).  Can it be removed?

Yes.
 

• The selection bar expands beyond the width of the tree in browsers using the W3C box-model.

Can you give an example? I'm not seeing this behavior anywhere.

         Thanks,

                   Emily

 

-Sam

On Jan 15, 2008 4:33 PM, Emily Crutcher <e...@google.com> wrote:

> Fast Tree is a new Tree API. It breaks the old Tree API in a couple of different ways, outlined below. It is 3-10 times faster then the old Tree as well.  
>
> Wiki, with links to demo and live code:
> http://code.google.com/p/google-web-toolkit-incubator/wiki/FastTree
>
> Main changes:
>
>
> FastTreeItem no longer uses image widgets, uses css background images instead.
> TreeListeners functionality  has been replaced with overridable methods from FastTreeItem  such  as  onSelected(), ensureChildren(), and  beforeOpen()      
>
> Selection now highlights horizontally using a selection bar. Users can customize how the bar highlights their items.
> Added HasFastTreeItems  interface for convenience when adding items to the tree or the tree items
> All styles delegated to CSS to allow user customization of tree.
>
> Uses StyleInjector library to provide default stylesheet for FastTree
>
>
> --
> "There are only 10 types of people in the world: Those who understand binary, and those who don't"
>

[John Tamplin]

On Jan 25, 2008 6:31 PM, Emily Crutcher <e...@google.com> wrote:

• Would it be possible to implement double-click to expand behavior on nodes? Trees on Windows and Mac have this behavior, and I think users are likely to expect it.

Can you elaborate a bit more on this one? I don't think I quite understand.

In a desktop app in most OSes, if you double-click on a tree item with children it will treat it as if you clicked on the +/- button (behavior varies as to whether it also fires a select event).
 

--
John A. Tamplin
Software Engineer, Google

[Emily Crutcher]

Thanks!

    It's a cool feature, but probably not one on my high priority list, though I'd be happy to work with someone who has a patch for it.

           Cheers,

                     Emily

[Sam Gross]

On Jan 25, 2008 6:31 PM, Emily Crutcher <e...@google.com> wrote:
> > The selection bar expands beyond the width of the tree in browsers using
> the W3C box-model.
> Can you give an example? I'm not seeing this behavior anywhere.
>

I attached a screenshot from Safari. The selection bar extends beyond
the edge of the tree (it's two pixels too wide). This also occurs in
Firefox, and I think will occur in Internet Explorer in standards mode
as well.

The width: 100% on the .selection-bar causes the content-area of the
selection bar to have the width of the FastTree. The border then
extends beyond the size of the FastTree.

The only solution I know of is to wrap the selection bar in another
div tag. You can then style them with something like:

.selection-bar-outer {
background: #e3e8f3 url('%selectionBar%') repeat-x;
font-size: 0;
position: absolute;
left: 0;
width: 100%;
}

.selection-bar-inner {
border: 1px solid black;
font-size: 0;
height: 100%;
}

I'm not a big fan of having to add another DOM element solely for
styling purposes, but I don't know of a better way. So much for CSS
allowing you to separate style from presentation. :-)

-Sam

[Emily Crutcher]

Ok, now I see what you mean, thanks!

[agelos.pikoulas]

Hi,

What do you think about convergence and incompatibility with existing
widgets?

Although we the community deeply appreciate all the great work that
you have done, I think it would be better if you focused more on
improving and incorporating great ideas into the existing native
widgets of GWT instead of spawning a completely new branch for Trees,
along with the existing alternatives that we already have for 'em
(GWT, MyGWT, gwtext, UFace etc).

I feel sometimes we have lost the meaning of reuse, although we live
in an OO Componetized world!

With kind regards,

Agelos

[John Tamplin]

On Mon, Feb 25, 2008 at 7:25 PM, agelos.pikoulas <agelos....@gmail.com> wrote:

What do you think about convergence and incompatibility with existing
widgets?

Although we the community deeply appreciate all the great work that
you have done, I think it would be better if you focused more on
improving and incorporating great ideas into the existing native
widgets of GWT instead of spawning a completely new branch for Trees,
along with the existing alternatives that we already have for 'em
(GWT, MyGWT, gwtext, UFace etc).

I feel sometimes we have lost the meaning of reuse, although we live
in an OO Componetized world!

The basic problem is that the API includes some design decisions that make it impossible to improve the performance.  We can either live with that limitation, in which case people will write their own widgets anyway or just avoid trees, or we can write a new tree which avoids those design flaws.

[agelos.pikoulas]

>
> The basic problem is that the API includes some design decisions that make
> it impossible to improve the performance. We can either live with that
> limitation, in which case people will write their own widgets anyway or just
> avoid trees, or we can write a new tree which avoids those design flaws.
>
> --
> John A. Tamplin
> Software Engineer, Google

Well, I cant "Object" to "this" ;-)

Reason is I haven't looked at the internals so deeply, but from the
surface I see many common
methods and fields.
Hence subclassing Tree & TreeItem with overriding of methods when
appropriate could be a good idea, but of course you know better!
The main concern is that end-user/developers should have
substitutability as an option.

Anyway, I think the GWT community should in general yield
getTogether() and create compatible widgets, building on what the main
GWT has, *unless* there is a damn good reason not to!

[Emily Crutcher]

Agelos, I think you've misunderstood the purpose of the gwt-incubator.   It is meant to be a place where we work on widgets and libraries for GWT.  

gwt-incubator is a separate project precisely so that we don't clutter up GWT's trunk with speculative libraries and widgets. We want our developers to feel confident when they are using the GWT trunk that the features they are using will not be taken out from under them.  

This means we need some place to develop the ideas, libraries, and apis that are needed for GWT's growth. We want to get not only designs out, but functioning code so that all the gotcha's that happen with widgets and library designs will happen before we inject that instability into GWT itself. 

Speaking of widget philosophy. Our first choice is always to improve the existing widgets.  Only if that is not possible do we introduce new widgets.  For instance, the current Tree was first upgraded to be as fast as we could make it under the constraints we had.  Then we looked at the other user requirements for trees and found there was no way to satisfy them without breaking the current tree. Therefore, we cloned Tree in incubator, and named it differently to avoid developer confusion.

In the end, one of three things will happen

• The new tree will replace the old and break some current users.
• We will introduce a new tree widget and make the old one a subclass of the new widget.
  
• We may decide that the new tree does not enjoy enough community support to be released as a public GWT widget and therefore retire it from the gwt-incubator.
  

gwt-incubator is not for all developers, precisely because it's mandate is not to preserve backward compatibility; instead it's purpose is to validate new ideas.  My guess is that you will probably be happier focusing on the widgets/libraries that we are sure enough of to be adding to GWT trunk rather then looking at the more speculative ones in the gwt-incubator.


     Cheers,

             Emily
 

On Mon, Feb 25, 2008 at 7:25 PM, agelos.pikoulas <agelos....@gmail.com> wrote: