[xwiki-devs] New WYSIWYG editor with or without dialogs?
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 not, how can we replace them? Thanks, Marius
Hi Marius, On Jun 12, 2008, at 2:03 PM, Marius Dumitru Florea wrote:
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 not, how can we replace them?
Is that also a problem with GWT 1.5? Thanks -Vincent
Hi Marius,
On Jun 12, 2008, at 2:03 PM, Marius Dumitru Florea wrote:
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 not, how can we replace them?
Is that also a problem with GWT 1.5?
This morning I tried to build with GWT 1.5 but: * we don't have 1.5 in our repos * there's no gwt-dev artifact on gwt-maven.googlecode.com repo * gwt-dev is messed up or missing in repo1.maven.org (they switched the version with the classifier only for linux; mac and windows versions are ok..) so I don't know if the problem persists in 1.5, but I suspect it does.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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. Jerome.
* if not, how can we replace them?
Thanks, Marius
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Jun 12, 2008, at 2:15 PM, Jerome Velociter wrote:
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.
I can't believe GWT is not able to that properly and that some simple javascript like we had was able to do it. Is that a known issue of GWT? Before we decide to use a degraded solution I'd like to be sure there's no other way. Thanks -Vincent
On Jun 12, 2008, at 2:15 PM, Jerome Velociter wrote:
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.
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.
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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.
Yes, I'd like to show only a dashed (maybe) border and, possibly, a background-color with some opacity level. This way I move only a div with its border, background-color and opacity and hide or leave in the same place the dialog box, while dragging.
Jerome.
* if not, how can we replace them?
Thanks, Marius
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Jun 12, 2008, at 2:26 PM, Marius Dumitru Florea wrote:
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.
Yes, I'd like to show only a dashed (maybe) border and, possibly, a background-color with some opacity level. This way I move only a div with its border, background-color and opacity and hide or leave in the same place the dialog box, while dragging.
hmm... so it means we're doing pretty low level stuff and that GWT is not offering much tools. I'm a bit worried that we're developing more than we should. This will mean lots of maintenance too. Isn't there any existing solutions for this? Thanks -Vincent PS: Please bear with me as I've never developed with GWT so I don't know what's available or not.
On Jun 12, 2008, at 2:26 PM, Marius Dumitru Florea wrote:
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.
Yes, I'd like to show only a dashed (maybe) border and, possibly, a background-color with some opacity level. This way I move only a div with its border, background-color and opacity and hide or leave in the same place the dialog box, while dragging.
hmm... so it means we're doing pretty low level stuff and that GWT is not offering much tools. I'm a bit worried that we're developing more than we should. This will mean lots of maintenance too.
Isn't there any existing solutions for this?
I'd say that what GWT gives us is not scalable all the time. I'll look for alternatives GWT libraries for both dialog boxes and drag&drop logic. But, you don't have something against using dialog boxes? I know Anca has.
Thanks -Vincent
PS: Please bear with me as I've never developed with GWT so I don't know what's available or not. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Jun 12, 2008, at 2:50 PM, Marius Dumitru Florea wrote:
On Jun 12, 2008, at 2:26 PM, Marius Dumitru Florea wrote:
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.
Yes, I'd like to show only a dashed (maybe) border and, possibly, a background-color with some opacity level. This way I move only a div with its border, background-color and opacity and hide or leave in the same place the dialog box, while dragging.
hmm... so it means we're doing pretty low level stuff and that GWT is not offering much tools. I'm a bit worried that we're developing more than we should. This will mean lots of maintenance too.
Isn't there any existing solutions for this?
I'd say that what GWT gives us is not scalable all the time. I'll look for alternatives GWT libraries for both dialog boxes and drag&drop logic.
But, you don't have something against using dialog boxes? I know Anca has.
No that's fine with me. My only concern is limiting the amount of lines of code we write. The less we write the better it is. I'm really surprised there's no good already existing WYSIWYG editor based on GWT. It's a pity since I'm pretty sure it'll exist relatively soon and we'll already have done all our work... Since it's not XWiki's job to write WYSIWYG editors it's a pity we have to write it. If we could have focused on just choosing what controls we wanted + the html <-> wiki conversions that would have been better. Anyway that's probably the cost of being early adopters... I hope our editor will really rock thanks to that and keep us ahead of the competition :) (although when a real cool GWT editor is created the competition will be able to leapfrog us). Thanks -Vincent
Vincent Massol wrote:
I'm really surprised there's no good already existing WYSIWYG editor based on GWT. It's a pity since I'm pretty sure it'll exist relatively soon and we'll already have done all our work... Since it's not XWiki's job to write WYSIWYG editors it's a pity we have to write it. If we could have focused on just choosing what controls we wanted + the html <-> wiki conversions that would have been better.
Anyway that's probably the cost of being early adopters... I hope our editor will really rock thanks to that and keep us ahead of the competition :) (although when a real cool GWT editor is created the competition will be able to leapfrog us).
Well, after we have the first working version, we can release it as a generic editor, so we can be that really cool GWT editor. If it's outside, we won't be able to control it (as in "strongly request the features we need"). If we manage to make it generic enough to attract a community, we can emphasize the features we need, and let others make it glittery and shiny, so we'll have the best editor custom made for XWiki. So Marius, keep in mind that any XWiki specific feature must not be hard wired in the editor. -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Jun 13, 2008, at 3:30 PM, Sergiu Dumitriu wrote:
Vincent Massol wrote:
I'm really surprised there's no good already existing WYSIWYG editor based on GWT. It's a pity since I'm pretty sure it'll exist relatively soon and we'll already have done all our work... Since it's not XWiki's job to write WYSIWYG editors it's a pity we have to write it. If we could have focused on just choosing what controls we wanted + the html <-> wiki conversions that would have been better.
Anyway that's probably the cost of being early adopters... I hope our editor will really rock thanks to that and keep us ahead of the competition :) (although when a real cool GWT editor is created the competition will be able to leapfrog us).
Well, after we have the first working version, we can release it as a generic editor, so we can be that really cool GWT editor. If it's outside, we won't be able to control it (as in "strongly request the features we need"). If we manage to make it generic enough to attract a community, we can emphasize the features we need, and let others make it glittery and shiny, so we'll have the best editor custom made for XWiki.
Yes I know we could do this and I even agree completely in theory... but... creating a community and making a generic product is a *LOT* of work and we don't have half of the required manpower to do that. It's already difficult enough to do it for XWiki and we don't want to take away people from the XWiki so that they spend all their time on fostering a GWT WYSIWYG editor community IMO. Now IF someone approaches us and that person want to separate our WYSIWYG editor and make it an external project then yes that'd be great and the best and we could support that person. But supporting and doing it are a very different things. -Vincent
So Marius, keep in mind that any XWiki specific feature must not be hard wired in the editor.
On Jun 12, 2008, at 2:26 PM, Marius Dumitru Florea wrote:
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.
Yes, I'd like to show only a dashed (maybe) border and, possibly, a background-color with some opacity level. This way I move only a div with its border, background-color and opacity and hide or leave in the same place the dialog box, while dragging.
hmm... so it means we're doing pretty low level stuff and that GWT is not offering much tools. I'm a bit worried that we're developing more than we should. This will mean lots of maintenance too.
I'm afraid I'll have to do lower level stuff for the rich text area (part of witch is already done). GWT is a nice framework in photos but when you meet him in person you realize you have to do many things by yourself. Nevertheless it allows you to write Java code instead of JavaScript, which is very important.
Isn't there any existing solutions for this?
I'd say that what GWT gives us is not scalable all the time. I'll look for alternatives GWT libraries for both dialog boxes and drag&drop logic.
But, you don't have something against using dialog boxes? I know Anca has.
Thanks -Vincent
PS: Please bear with me as I've never developed with GWT so I don't know what's available or not. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Jun 12, 2008, at 3:02 PM, Marius Dumitru Florea wrote: [snip]
I'm afraid I'll have to do lower level stuff for the rich text area (part of witch is already done). GWT is a nice framework in photos but when you meet him in person you realize you have to do many things by yourself.
:)
Nevertheless it allows you to write Java code instead of JavaScript, which is very important.
Yes, except like you taught me, it's not really "Java", it's Java without all the frameworks out there... -Vincent
On Jun 12, 2008, at 2:26 PM, Marius Dumitru Florea wrote:
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.
Yes, I'd like to show only a dashed (maybe) border and, possibly, a background-color with some opacity level. This way I move only a div with its border, background-color and opacity and hide or leave in the same place the dialog box, while dragging.
hmm... so it means we're doing pretty low level stuff and that GWT is not offering much tools. I'm a bit worried that we're developing more than we should. This will mean lots of maintenance too.
Isn't there any existing solutions for this?
I'd say that what GWT gives us is not scalable all the time. I'll look for alternatives GWT libraries for both dialog boxes and drag&drop logic.
But, you don't have something against using dialog boxes? I know Anca has.
I only have something against dialogs when they're used everywhere as a rule, including places that have no modal semantic: like choosing the color of the text. Honestly, I don't see any reason at all why this have to be a dialog. As for other situations (like adding an image to the document), indeed, a dialog seems like the most natural choice... I should mention that when I think about dialogs in a RIA I think about modal dialogs. Non-modals cause a lot of mess in desktop apps already, I don't even want to imagine what they could do in a web app. I'm no HCI expert, I think we some opinions from people that know / have seen more of it would help a lot. pretty interesting reading about dialogs and gwt versions: http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/8fd33... Happy coding, Anca
Thanks -Vincent
PS: Please bear with me as I've never developed with GWT so I don't know what's available or not. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Jun 12, 2008, at 3:24 PM, [email protected] wrote: [snip]
I'd say that what GWT gives us is not scalable all the time. I'll look for alternatives GWT libraries for both dialog boxes and drag&drop logic.
But, you don't have something against using dialog boxes? I know Anca has.
I only have something against dialogs when they're used everywhere as a rule, including places that have no modal semantic: like choosing the color of the text. Honestly, I don't see any reason at all why this have to be a dialog.
Right. A drop down box should be enough for this.
As for other situations (like adding an image to the document), indeed, a dialog seems like the most natural choice... I should mention that when I think about dialogs in a RIA I think about modal dialogs. Non-modals cause a lot of mess in desktop apps already, I don't even want to imagine what they could do in a web app.
I'm no HCI expert, I think we some opinions from people that know / have seen more of it would help a lot.
pretty interesting reading about dialogs and gwt versions: http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/8fd33...
They reverted it apparently. -Vincent
Marius Dumitru Florea wrote:
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).
Are you sure it's not a Linux+Firefox bug? In some systems, the browser is very slow when rendering floating elements and transparent images. You should ask someone on windows to try. -- Sergiu Dumitriu http://purl.org/net/sergiu/
participants (5)
-
ancapaula.luca＠xwiki.com -
Jerome Velociter -
Marius Dumitru Florea -
Sergiu Dumitriu -
Vincent Massol