On Wed, Apr 2, 2008 at 5:19 AM, Fabian Jakobs <[EMAIL PROTECTED]>
wrote:
> I am about to port the old tree to 0.8. While doing so I realized that it
> might be a good idea to manage the tree as a list instead of a nested widget
> structure. I dismissed the idea because it would have resulted in a
> completely different API with no performance gains. Simply porting the tree
> is not really an option because it reached deep into the old widget system.
Tree is one of the more difficult widgets to figure out because it reached
so deeply into the widget system. I would certainly welcome changes to
that! :-)
As I'm sure you know, TreeVirtual uses a "list" approach, since it is
implemented on top of Table. The disadvantage is that the tree needs to be
recalculated each time changes are applied. (Tests prove, however, that
even with large trees, that recalculation is not terribly significant and
generally not noticeable in normal use.) A benefit of the list approach,
and I suspect that this would influence me considerably if I were to be
creating a new interface for Tree, is that one can use a "model" interface
in addition to manual manipulation of individual elements of the tree. I
find the model to be much cleaner for reasonably static trees.
>
> I now do a mixed approach. I start with a clean tree but still use the
> nested widget approach. I try to keep the API stable and copy code, which
> doesn't need to change from the old implementation. There are some things we
> would like to change:
>
> 1. Get rid of the tree lines. No modern UI system uses them anymore. The
> usability guy, who did the new qooxdoo theme told us that they are actually
> distracting people. The code to handle tree lines is really bloat and they
> make it hard to have different row heights in the tree.
>
If 0.8 removes the tree lines, it would be a complete show-stopper for me.
Those lines are absolutely necessary whenever one has a fairly large,
deeply-opened tree. Without them, it's near impossible to figure out the
parent of a node if the parent is not visible without scrolling. I would be
unable to use 0.8 until tree lines were re-added.
So, based on that, I'd beg to differ on the comment that the code to handle
the tree lines is bloat. To the contrary, I consider it mandatory code.
As to being difficult to have different row heights... That's true, using
the existing scheme with fixed icons as the tree lines, it is difficult
(unless one were willing to dynamically generate the icons on the fly).
However, it's worth considering an alternate scheme where the vertical lines
are the "border" of a div placed where the line belongs. If the div has
height:100%, that border (vertical tree line) would grow in height to take
up the entire height, regardless of the row's height. Experimenting with
something along those lines is probably worthwhile if variable row height
for trees is deemed necessary. (Although I've seen multiple requests for
variable row height tables, I've not seen a single request for variable row
height trees.)
> 2. Remove the tree row structure and find a better way to customize tree
> items. My first goal in this direction is to make the tree file and tree
> folder widgets easier to subclass. May be implement something similar to the
> tree row structure API directly in the tree element API.
When I first implemented the tree row structure, I put a fair amount of
thought into how to represent that. At the time, I was new to qooxdoo and
also constrained myself to implementations that would merge with the
original Tree implementation. (My original patch set which predated
TreeFullControl was actually a set of patches directly to Tree.) As stated
above, if I were to implement that now, with a clean slate for API, I think
I'd probably implement something that allowed for a "model" interface.
>
> 3. The tree widget no longer derives from tree folder but acts as a
> container for tree items.
>
I have no problem with that! The current implementation never quite made
sense to me.
Hope that helps!
Derrell
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
