Your English is very good. No problems there!
I don't know the answer to your problem exactly as you're written it, but you
could possibly achieve the same thing a different way. Take a look at the tree
dag-and-drop method done here:
https://code.google.com/p/gwt-dnd-tree/
It indicates the drop position by drawing a line in the appropriate place to
indicate where the drop is. You can use the same technique to draw anything you
like to indicate where the drop will be. If your requirements would allow
something similar, then you could avoid modifying anything in the tree itself,
and so avoid the problems of speed in event callbacks due to the tree size.
HTH
Paul
On 07/08/13 15:48, herrtribo...@gmail.com wrote:
>
> It's my first question here, and i'm not an english native speaker, so i
> apologize in advance, if that makes my explainations difficult to understand.
>
>
> CONTEXT
>
> I'm in charge of the developpement of a small application which manipulate
> vocabulary sets. The application is built on GWT, added by GWT-Bootstrap and
> some other libraries, that have nothing to do with the ui part of the
> application. To expose to the user the terms of this vocabulary, i use a tree
> stucture, visually speaking.
>
>
> STORY
>
> The tree has few requirements, it has to allow drag&drop features for his
> items and show connectors between them.
>
> I started by using the Tree ui class from the native GWT components. It
> turned out that with a lot of terms loaded in the tree, the performances felt
> down, even in production mode.
>
> I decided so to try the CellTree implementation, but it didn't fit for me
> since make disappear the "showmore" button is not an easy task, and styling
> the tree too.
>
> I finally ends up with my own implementation of a tree, from scratch. This
> implementation relies essentially on a simple html list structure (ul-li),
> and benefits at maximum of css capabilities. Indeed, expanding a tree node is
> done with css, using a trick known as "checkbox hack".
>
> At this point the custom implementation of the tree is fast (better than tree
> or celltree), even populated with thousands items, and it met the
> requirements, but...
>
>
> THE ISSUE
>
> When an item is being dragged over other items, the style of those items
> change depending on dropping possibilities.
>
>
> 1st Solution
>
> The first idea was to benefit of the css, and use the :hover selector to
> change the style of the items, depending on their classes. But there is a
> major issue in current browsers (specifically Chrome), which make the css
> :hover not triggered, if the mouse left button is down, which it's the case
> when you drag something (chromium issue 122746)
>
> It seems that i have to forgot an exculsive css solution, until the :hover
> triggering issue will be closed.
>
>
> 2nd solution
>
> The only other solution to which i came by is to change the style of the item
> programmatically.
>
> Code of the handler
>
> |@Override
> public void onDragEnter(DragEnterEvent event)
> {
> if (event.getSource() instanceof Word)
> {
> event.stopPropagation();
> event.preventDefault();
> Word word = (Word) event.getSource();
> word.addStyleDependentName("over");
> }
> }
> @Override
> public void onDragLeave(DragLeaveEvent event)
> {
> if (event.getSource() instanceof Word)
> {
> event.stopPropagation();
> event.preventDefault();
> Word word = (Word) event.getSource();
> word.removeStyleDependentName("over");
> }
> }
> |
>
> It works fine with a few items, but when dealing with thousands it make the
> application freezing, and the rendering is somehow random.
>
>
> PRECISIONS
>
> The issue appears when dealing with 5000 items in the tree (the application
> must handle such dataset).
>
> I'm aware of efficient events handling concerns, as event bubbling, and the
> handler is unique as it is recommanded when the number of potential handlers,
> if made specific for each item, is a factor of lack of performance as the
> number of items increase.
>
> Secondary i've used the speed tracer to analyse the source of the problem,
> *and it turned out something i don't understand*:
>
> Events are incredibly slow on top elements of the tree, specifically the
> paint event which take 1 second to be fired after the style recalculation
> Slow events Speed Tracer Screenshot <http://i.stack.imgur.com/Kvhka.png>
>
> Events speed is fair enougth on bottom elements of the tree Fair enougth
> speed events Speed Tracer Screenshot <http://i.stack.imgur.com/6Cb4m.png>
>
>
> QUESTION
>
> I'm stuck with this issue since few days, and i wonder if someone could point
> out what i am missing. Perhaps, the behaviour is totally normal, but maybe
> there is a workaround for a such issue ? I'll be glad if someone could help
> me on this point.
>
> Thanks you for any reply !
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google Web Toolkit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.
