12 Jun
2008
12 Jun
'08
2:41 p.m.
On Jun 12, 2008, at 2:15 PM, Jerome Velociter wrote:
I can't believe GWT is not able to that properly and that some simple
javascript like we had was able to do it.
Vincent, the current WYSIWYG editor uses windows for implementing the
dialog boxes. When you want to pick a color you open a window. You can see
it in the desktop toolbar. You can see it even if you change the browser
tab, which is not nice. Of course these windows are easily moved because
the OS take care of that.
In GWT dialog boxes are implemented using HTML elements (div for instance)
and JavaScript for catching mouse moves and simulating drag&drop.
Hi devs,
While working on the new GWT-based WYSIWYG editor, I find out that
the
default DialogBox from GWT moves very slow when dragged if it
contains
many HTML elements (like a table with 10 rows and 20 columns). In the
current WYSIWYG editor dialog boxes are used for color picker, custom
character, insert image / attachment / macro / table. Before I start
porting these dialogs to GWT I'd like to ask you:
Do you agree with using dialog boxes for these features?
* if so, do you think it's ok to optimize the way they are moved by
showing only their border while dragging (win95-like)?
If you do so, what are you showing instead of the dialog content ? the
content behind ? or a plain color ?
I think the main use case (if not the only ?) for moving such
dialogs is
to see what's behind. In that case showing only the border and let the
user see what's behind is good IMO. Is that a known issue of GWT?
Yes. But I don't think the default DialogBox was made to be scalable. If
you put only a button or so it moves very fast. I did some tests and it
moves slower and slower as you put more HTML elements.
Before we decide to use a degraded solution I'd like to be sure
there's no other way.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs