[xwiki-devs] [Proposal] Use a modifier key with click to collapse/expand macros inside the WYSIWYG editor
Hi devs, Currently we have this behavior: * simple click to select a macro * simple click to toggle between collapsed and expanded state of a previously selected macro * double click to edit the macro properties The problem is that the double click event consists, as its name suggests, in two consecutive click events. As a consequence, when you double click to edit a macro you also toggle its visibility state. Besides being annoying, this can lead sometimes to an unexpected result: ----- <details> ----- I inserted a really long code macro (paste an entire Java source file). and them selected the macro and double clicked somewhere in the middle to edit its properties. This is what happened: * The first click event collapsed the macro * The second click event was not fired on the macro but on document body, because after the macro collapsed the place where I clicked was in the middle of nowhere. As a result the macro was unselected. * the (logical) double click event was still fired on the macro (I guess because the target of the first click was the macro container) and thus the edit macro dialog opened * I changed the macro properties and closed the dialog. As a result the macro was duplicated. The edit dialog should have replaced the selected macro but there was no selected macro.. ----- </details> ----- Therefore I propose to use a modifier key with click to collapse/expand a macro. I'm not sure which modifier key is the best. I think we should choose between Alt and Meta. The behavior would become: * simple click to select a macro * [Alt or Meta] + simple click to toggle the collapsed and expanded state * double click to edit I'm +1 for Alt key. WDYT? Thanks, Marius
On Wed, Dec 16, 2009 at 08:30, Marius Dumitru Florea <[email protected]> wrote:
Hi devs,
Currently we have this behavior:
* simple click to select a macro * simple click to toggle between collapsed and expanded state of a previously selected macro * double click to edit the macro properties
The problem is that the double click event consists, as its name suggests, in two consecutive click events. As a consequence, when you double click to edit a macro you also toggle its visibility state. Besides being annoying, this can lead sometimes to an unexpected result:
----- <details> ----- I inserted a really long code macro (paste an entire Java source file). and them selected the macro and double clicked somewhere in the middle to edit its properties. This is what happened:
* The first click event collapsed the macro * The second click event was not fired on the macro but on document body, because after the macro collapsed the place where I clicked was in the middle of nowhere. As a result the macro was unselected. * the (logical) double click event was still fired on the macro (I guess because the target of the first click was the macro container) and thus the edit macro dialog opened * I changed the macro properties and closed the dialog. As a result the macro was duplicated. The edit dialog should have replaced the selected macro but there was no selected macro.. ----- </details> -----
Therefore I propose to use a modifier key with click to collapse/expand a macro. I'm not sure which modifier key is the best. I think we should choose between Alt and Meta. The behavior would become:
* simple click to select a macro * [Alt or Meta] + simple click to toggle the collapsed and expanded state * double click to edit
I'm +1 for Alt key.
WDYT?
What about having to click in a specific area like a +/- in the top left corner to toggle the collapsed and expanded state ? This sounds a lot easier and natural for a user, most of users will never remember how to do it if it's " [Alt or Meta] + simple click".
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Hi, On Wed, Dec 16, 2009 at 9:48 AM, Thomas Mortagne <[email protected]>wrote:
On Wed, Dec 16, 2009 at 08:30, Marius Dumitru Florea <[email protected]> wrote:
Hi devs,
Currently we have this behavior:
* simple click to select a macro * simple click to toggle between collapsed and expanded state of a previously selected macro * double click to edit the macro properties
The problem is that the double click event consists, as its name suggests, in two consecutive click events. As a consequence, when you double click to edit a macro you also toggle its visibility state. Besides being annoying, this can lead sometimes to an unexpected result:
----- <details> ----- I inserted a really long code macro (paste an entire Java source file). and them selected the macro and double clicked somewhere in the middle to edit its properties. This is what happened:
* The first click event collapsed the macro * The second click event was not fired on the macro but on document body, because after the macro collapsed the place where I clicked was in the middle of nowhere. As a result the macro was unselected. * the (logical) double click event was still fired on the macro (I guess because the target of the first click was the macro container) and thus the edit macro dialog opened * I changed the macro properties and closed the dialog. As a result the macro was duplicated. The edit dialog should have replaced the selected macro but there was no selected macro.. ----- </details> -----
Therefore I propose to use a modifier key with click to collapse/expand a macro. I'm not sure which modifier key is the best. I think we should choose between Alt and Meta. The behavior would become:
* simple click to select a macro * [Alt or Meta] + simple click to toggle the collapsed and expanded state * double click to edit
I'm +1 for Alt key.
WDYT?
What about having to click in a specific area like a +/- in the top left corner to toggle the collapsed and expanded state ? This sounds a lot easier and natural for a user, most of users will never remember how to do it if it's " [Alt or Meta] + simple click".
Yes, that's what I was thinking about too. A "minimize" button at the top right of the macro displayer would be better. Guillaume
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
Guillaume Lerouge wrote:
Hi,
On Wed, Dec 16, 2009 at 9:48 AM, Thomas Mortagne <[email protected]>wrote:
On Wed, Dec 16, 2009 at 08:30, Marius Dumitru Florea <[email protected]> wrote:
Hi devs,
Currently we have this behavior:
* simple click to select a macro * simple click to toggle between collapsed and expanded state of a previously selected macro * double click to edit the macro properties
The problem is that the double click event consists, as its name suggests, in two consecutive click events. As a consequence, when you double click to edit a macro you also toggle its visibility state. Besides being annoying, this can lead sometimes to an unexpected result:
----- <details> ----- I inserted a really long code macro (paste an entire Java source file). and them selected the macro and double clicked somewhere in the middle to edit its properties. This is what happened:
* The first click event collapsed the macro * The second click event was not fired on the macro but on document body, because after the macro collapsed the place where I clicked was in the middle of nowhere. As a result the macro was unselected. * the (logical) double click event was still fired on the macro (I guess because the target of the first click was the macro container) and thus the edit macro dialog opened * I changed the macro properties and closed the dialog. As a result the macro was duplicated. The edit dialog should have replaced the selected macro but there was no selected macro.. ----- </details> -----
Therefore I propose to use a modifier key with click to collapse/expand a macro. I'm not sure which modifier key is the best. I think we should choose between Alt and Meta. The behavior would become:
* simple click to select a macro * [Alt or Meta] + simple click to toggle the collapsed and expanded state * double click to edit
I'm +1 for Alt key.
WDYT? What about having to click in a specific area like a +/- in the top left corner to toggle the collapsed and expanded state ? This sounds a lot easier and natural for a user, most of users will never remember how to do it if it's " [Alt or Meta] + simple click".
Yes, that's what I was thinking about too. A "minimize" button at the top right of the macro displayer would be better.
IMO macros should look as in view mode when expanded. Right now this is not happening all the time due to the current implementation which uses buttons to protect the macro output and buttons have an inherent inline-block display. But in the future, when the contentEditable attribute will be fully supported, we should have: before |this is a multiple line macro output blah blah blah blah blah blah blah| after instead of before |this is a multiple | after |line macro output | |blah blah blah blah| |blah blah blah | Thus putting a +/- sign in the top left corner seems artificial to me, considering that the macro output is not necessarily a box. Coming back to the current implementation, I don't think it's possible to have a button inside another button and to catch the click event for the inner button because you can't actually click the inner button without clicking the outer button. If that would work then you would be able to interact with the macro output in edit mode (e.g. click links, move to the next page in a live table, etc.), which doesn't happen right now. Thanks, Marius
Guillaume
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 12/16/2009 11:22 AM, Marius Dumitru Florea wrote:
Guillaume Lerouge wrote:
Hi,
On Wed, Dec 16, 2009 at 9:48 AM, Thomas Mortagne <[email protected]>wrote:
On Wed, Dec 16, 2009 at 08:30, Marius Dumitru Florea <[email protected]> wrote:
Hi devs,
Currently we have this behavior:
* simple click to select a macro * simple click to toggle between collapsed and expanded state of a previously selected macro * double click to edit the macro properties
The problem is that the double click event consists, as its name suggests, in two consecutive click events. As a consequence, when you double click to edit a macro you also toggle its visibility state. Besides being annoying, this can lead sometimes to an unexpected result:
-----<details> ----- I inserted a really long code macro (paste an entire Java source file). and them selected the macro and double clicked somewhere in the middle to edit its properties. This is what happened:
* The first click event collapsed the macro * The second click event was not fired on the macro but on document body, because after the macro collapsed the place where I clicked was in the middle of nowhere. As a result the macro was unselected. * the (logical) double click event was still fired on the macro (I guess because the target of the first click was the macro container) and thus the edit macro dialog opened * I changed the macro properties and closed the dialog. As a result the macro was duplicated. The edit dialog should have replaced the selected macro but there was no selected macro.. -----</details> -----
Therefore I propose to use a modifier key with click to collapse/expand a macro. I'm not sure which modifier key is the best. I think we should choose between Alt and Meta. The behavior would become:
* simple click to select a macro * [Alt or Meta] + simple click to toggle the collapsed and expanded state * double click to edit
I'm +1 for Alt key.
WDYT? What about having to click in a specific area like a +/- in the top left corner to toggle the collapsed and expanded state ? This sounds a lot easier and natural for a user, most of users will never remember how to do it if it's " [Alt or Meta] + simple click".
Yes, that's what I was thinking about too. A "minimize" button at the top right of the macro displayer would be better.
IMO macros should look as in view mode when expanded. Right now this is not happening all the time due to the current implementation which uses buttons to protect the macro output and buttons have an inherent inline-block display. But in the future, when the contentEditable attribute will be fully supported, we should have:
before |this is a multiple line macro output blah blah blah blah blah blah blah| after
instead of
before |this is a multiple | after |line macro output | |blah blah blah blah| |blah blah blah |
Thus putting a +/- sign in the top left corner seems artificial to me, considering that the macro output is not necessarily a box.
Coming back to the current implementation, I don't think it's possible to have a button inside another button and to catch the click event for the inner button because you can't actually click the inner button without clicking the outer button. If that would work then you would be able to interact with the macro output in edit mode (e.g. click links, move to the next page in a live table, etc.), which doesn't happen right now.
It doesn't have to be a button inside a button. How about a small + icon that appears only when hovering over the macro, overlapping the content, so it doesn't appear like a window button, but more like the + button in Dolphin (KDE 4) which allows to add documents to the selection. Technically it could be a div outside the macro, absolute position, z-index, and all the stuff that makes it appear over the macro. Can GWT handle that? Extreme example: what happens with the Footnote macro, whose content is tiny? -- Sergiu Dumitriu http://purl.org/net/sergiu/
Sergiu Dumitriu wrote:
On 12/16/2009 11:22 AM, Marius Dumitru Florea wrote:
Guillaume Lerouge wrote:
Hi,
On Wed, Dec 16, 2009 at 9:48 AM, Thomas Mortagne <[email protected]>wrote:
On Wed, Dec 16, 2009 at 08:30, Marius Dumitru Florea <[email protected]> wrote:
Hi devs,
Currently we have this behavior:
* simple click to select a macro * simple click to toggle between collapsed and expanded state of a previously selected macro * double click to edit the macro properties
The problem is that the double click event consists, as its name suggests, in two consecutive click events. As a consequence, when you double click to edit a macro you also toggle its visibility state. Besides being annoying, this can lead sometimes to an unexpected result:
-----<details> ----- I inserted a really long code macro (paste an entire Java source file). and them selected the macro and double clicked somewhere in the middle to edit its properties. This is what happened:
* The first click event collapsed the macro * The second click event was not fired on the macro but on document body, because after the macro collapsed the place where I clicked was in the middle of nowhere. As a result the macro was unselected. * the (logical) double click event was still fired on the macro (I guess because the target of the first click was the macro container) and thus the edit macro dialog opened * I changed the macro properties and closed the dialog. As a result the macro was duplicated. The edit dialog should have replaced the selected macro but there was no selected macro.. -----</details> -----
Therefore I propose to use a modifier key with click to collapse/expand a macro. I'm not sure which modifier key is the best. I think we should choose between Alt and Meta. The behavior would become:
* simple click to select a macro * [Alt or Meta] + simple click to toggle the collapsed and expanded state * double click to edit
I'm +1 for Alt key.
WDYT? What about having to click in a specific area like a +/- in the top left corner to toggle the collapsed and expanded state ? This sounds a lot easier and natural for a user, most of users will never remember how to do it if it's " [Alt or Meta] + simple click".
Yes, that's what I was thinking about too. A "minimize" button at the top right of the macro displayer would be better. IMO macros should look as in view mode when expanded. Right now this is not happening all the time due to the current implementation which uses buttons to protect the macro output and buttons have an inherent inline-block display. But in the future, when the contentEditable attribute will be fully supported, we should have:
before |this is a multiple line macro output blah blah blah blah blah blah blah| after
instead of
before |this is a multiple | after |line macro output | |blah blah blah blah| |blah blah blah |
Thus putting a +/- sign in the top left corner seems artificial to me, considering that the macro output is not necessarily a box.
Coming back to the current implementation, I don't think it's possible to have a button inside another button and to catch the click event for the inner button because you can't actually click the inner button without clicking the outer button. If that would work then you would be able to interact with the macro output in edit mode (e.g. click links, move to the next page in a live table, etc.), which doesn't happen right now.
It doesn't have to be a button inside a button. How about a small + icon that appears only when hovering over the macro, overlapping the content, so it doesn't appear like a window button, but more like the + button in Dolphin (KDE 4) which allows to add documents to the selection. Technically it could be a div outside the macro, absolute position, z-index, and all the stuff that makes it appear over the macro. Can GWT handle that?
If you can do it in JavaScript then you can do it in GWT. But is it worth implementing such a complex solution when it's so simple to use a shortcut. Now, let's say we go this way. Where exactly should we place the icon? I have a code macro that contains a large source file. When rendered inside the rich text area it takes a few "pages", i.e. you have to scroll to get from the start to the end. Also, it takes all the available width. Wherever I move the mouse the macro is hovered. Should the icon by displayed near the mouse cursor? Should be icon move with the mouse? If I place the mouse in the top left corned the icon should be place in the bottom right side of the mouse cursor. If I place the mouse cursor in the bottom right cornet then the icon should be placed in the top left side of the mouse cursor, etc. + make sure this works on all browsers. IMO this is too complicated with a lot of special use cases to take care of.
Extreme example: what happens with the Footnote macro, whose content is tiny?
WDYM? You think the user won't be able to collapse it? Why collapse it if it doesn't take space? Also note that macros without content are collapsed by default and can't be expanded. Marius
On 12/16/2009 04:30 PM, Marius Dumitru Florea wrote:
Sergiu Dumitriu wrote:
On 12/16/2009 11:22 AM, Marius Dumitru Florea wrote:
Guillaume Lerouge wrote:
Hi,
On Wed, Dec 16, 2009 at 9:48 AM, Thomas Mortagne <[email protected]>wrote:
On Wed, Dec 16, 2009 at 08:30, Marius Dumitru Florea <[email protected]> wrote:
Hi devs,
Currently we have this behavior:
* simple click to select a macro * simple click to toggle between collapsed and expanded state of a previously selected macro * double click to edit the macro properties
The problem is that the double click event consists, as its name suggests, in two consecutive click events. As a consequence, when you double click to edit a macro you also toggle its visibility state. Besides being annoying, this can lead sometimes to an unexpected result:
-----<details> ----- I inserted a really long code macro (paste an entire Java source file). and them selected the macro and double clicked somewhere in the middle to edit its properties. This is what happened:
* The first click event collapsed the macro * The second click event was not fired on the macro but on document body, because after the macro collapsed the place where I clicked was in the middle of nowhere. As a result the macro was unselected. * the (logical) double click event was still fired on the macro (I guess because the target of the first click was the macro container) and thus the edit macro dialog opened * I changed the macro properties and closed the dialog. As a result the macro was duplicated. The edit dialog should have replaced the selected macro but there was no selected macro.. -----</details> -----
Therefore I propose to use a modifier key with click to collapse/expand a macro. I'm not sure which modifier key is the best. I think we should choose between Alt and Meta. The behavior would become:
* simple click to select a macro * [Alt or Meta] + simple click to toggle the collapsed and expanded state * double click to edit
I'm +1 for Alt key.
WDYT? What about having to click in a specific area like a +/- in the top left corner to toggle the collapsed and expanded state ? This sounds a lot easier and natural for a user, most of users will never remember how to do it if it's " [Alt or Meta] + simple click".
Yes, that's what I was thinking about too. A "minimize" button at the top right of the macro displayer would be better. IMO macros should look as in view mode when expanded. Right now this is not happening all the time due to the current implementation which uses buttons to protect the macro output and buttons have an inherent inline-block display. But in the future, when the contentEditable attribute will be fully supported, we should have:
before |this is a multiple line macro output blah blah blah blah blah blah blah| after
instead of
before |this is a multiple | after |line macro output | |blah blah blah blah| |blah blah blah |
Thus putting a +/- sign in the top left corner seems artificial to me, considering that the macro output is not necessarily a box.
Coming back to the current implementation, I don't think it's possible to have a button inside another button and to catch the click event for the inner button because you can't actually click the inner button without clicking the outer button. If that would work then you would be able to interact with the macro output in edit mode (e.g. click links, move to the next page in a live table, etc.), which doesn't happen right now.
It doesn't have to be a button inside a button. How about a small + icon that appears only when hovering over the macro, overlapping the content, so it doesn't appear like a window button, but more like the + button in Dolphin (KDE 4) which allows to add documents to the selection. Technically it could be a div outside the macro, absolute position, z-index, and all the stuff that makes it appear over the macro. Can GWT handle that?
If you can do it in JavaScript then you can do it in GWT. But is it worth implementing such a complex solution when it's so simple to use a shortcut. Now, let's say we go this way. Where exactly should we place the icon? I have a code macro that contains a large source file. When rendered inside the rich text area it takes a few "pages", i.e. you have to scroll to get from the start to the end. Also, it takes all the available width. Wherever I move the mouse the macro is hovered. Should the icon by displayed near the mouse cursor? Should be icon move with the mouse? If I place the mouse in the top left corned the icon should be place in the bottom right side of the mouse cursor. If I place the mouse cursor in the bottom right cornet then the icon should be placed in the top left side of the mouse cursor, etc. + make sure this works on all browsers. IMO this is too complicated with a lot of special use cases to take care of.
OK, agreed. I forgot about the Macro menu, so since there is an alternative, +1 for the shortcut. The tooltip idea is nice, too.
Extreme example: what happens with the Footnote macro, whose content is tiny?
WDYM? You think the user won't be able to collapse it? Why collapse it if it doesn't take space? Also note that macros without content are collapsed by default and can't be expanded.
This was an example against the button approach, since the footnote doesn't have enough room to accommodate the collapse button. -- Sergiu Dumitriu http://purl.org/net/sergiu/
On 12/16/2009 10:23 AM, Guillaume Lerouge wrote:
Hi,
On Wed, Dec 16, 2009 at 9:48 AM, Thomas Mortagne <[email protected]>wrote:
On Wed, Dec 16, 2009 at 08:30, Marius Dumitru Florea <[email protected]> wrote:
Hi devs,
Currently we have this behavior:
* simple click to select a macro * simple click to toggle between collapsed and expanded state of a previously selected macro * double click to edit the macro properties
The problem is that the double click event consists, as its name suggests, in two consecutive click events. As a consequence, when you double click to edit a macro you also toggle its visibility state. Besides being annoying, this can lead sometimes to an unexpected result:
-----<details> ----- I inserted a really long code macro (paste an entire Java source file). and them selected the macro and double clicked somewhere in the middle to edit its properties. This is what happened:
* The first click event collapsed the macro * The second click event was not fired on the macro but on document body, because after the macro collapsed the place where I clicked was in the middle of nowhere. As a result the macro was unselected. * the (logical) double click event was still fired on the macro (I guess because the target of the first click was the macro container) and thus the edit macro dialog opened * I changed the macro properties and closed the dialog. As a result the macro was duplicated. The edit dialog should have replaced the selected macro but there was no selected macro.. -----</details> -----
Therefore I propose to use a modifier key with click to collapse/expand a macro. I'm not sure which modifier key is the best. I think we should choose between Alt and Meta. The behavior would become:
* simple click to select a macro * [Alt or Meta] + simple click to toggle the collapsed and expanded state * double click to edit
I'm +1 for Alt key.
WDYT?
What about having to click in a specific area like a +/- in the top left corner to toggle the collapsed and expanded state ? This sounds a lot easier and natural for a user, most of users will never remember how to do it if it's " [Alt or Meta] + simple click".
Yes, that's what I was thinking about too. A "minimize" button at the top right of the macro displayer would be better.
Guillaume
The same from me. I configured my system so that Meta+Click drags the window, so it never reaches the browser, although the default was Alt+Click. So any KDE users won't be able to use this feature. -- Sergiu Dumitriu http://purl.org/net/sergiu/
On 12/16/2009 03:14 PM, Sergiu Dumitriu wrote:
On 12/16/2009 10:23 AM, Guillaume Lerouge wrote:
Hi,
On Wed, Dec 16, 2009 at 9:48 AM, Thomas Mortagne <[email protected]>wrote:
On Wed, Dec 16, 2009 at 08:30, Marius Dumitru Florea <[email protected]> wrote:
Hi devs,
Currently we have this behavior:
* simple click to select a macro * simple click to toggle between collapsed and expanded state of a previously selected macro * double click to edit the macro properties
The problem is that the double click event consists, as its name suggests, in two consecutive click events. As a consequence, when you double click to edit a macro you also toggle its visibility state. Besides being annoying, this can lead sometimes to an unexpected result:
-----<details> ----- I inserted a really long code macro (paste an entire Java source file). and them selected the macro and double clicked somewhere in the middle to edit its properties. This is what happened:
* The first click event collapsed the macro * The second click event was not fired on the macro but on document body, because after the macro collapsed the place where I clicked was in the middle of nowhere. As a result the macro was unselected. * the (logical) double click event was still fired on the macro (I guess because the target of the first click was the macro container) and thus the edit macro dialog opened * I changed the macro properties and closed the dialog. As a result the macro was duplicated. The edit dialog should have replaced the selected macro but there was no selected macro.. -----</details> -----
Therefore I propose to use a modifier key with click to collapse/expand a macro. I'm not sure which modifier key is the best. I think we should choose between Alt and Meta. The behavior would become:
* simple click to select a macro * [Alt or Meta] + simple click to toggle the collapsed and expanded state * double click to edit
I'm +1 for Alt key.
WDYT?
What about having to click in a specific area like a +/- in the top left corner to toggle the collapsed and expanded state ? This sounds a lot easier and natural for a user, most of users will never remember how to do it if it's " [Alt or Meta] + simple click".
Yes, that's what I was thinking about too. A "minimize" button at the top right of the macro displayer would be better.
Guillaume
The same from me. I configured my system so that Meta+Click drags the window, so it never reaches the browser, although the default was Alt+Click. So any KDE users won't be able to use this feature.
But this type of collision could happen with any shortcut anywhere. Take for example the meta+G shortcut that we have for page jump which collides with the 'find previous' in ff browsers. I don't think this is a real stopper unless we make sure none of our shortcuts collide with anything ever, which is virtually impossible. Happy hacking, Anca
On 12/16/2009 03:16 PM, Anca Luca wrote:
On 12/16/2009 03:14 PM, Sergiu Dumitriu wrote:
On 12/16/2009 10:23 AM, Guillaume Lerouge wrote:
Hi,
On Wed, Dec 16, 2009 at 9:48 AM, Thomas Mortagne <[email protected]>wrote:
On Wed, Dec 16, 2009 at 08:30, Marius Dumitru Florea <[email protected]> wrote:
Hi devs,
Currently we have this behavior:
* simple click to select a macro * simple click to toggle between collapsed and expanded state of a previously selected macro * double click to edit the macro properties
The problem is that the double click event consists, as its name suggests, in two consecutive click events. As a consequence, when you double click to edit a macro you also toggle its visibility state. Besides being annoying, this can lead sometimes to an unexpected result:
-----<details> ----- I inserted a really long code macro (paste an entire Java source file). and them selected the macro and double clicked somewhere in the middle to edit its properties. This is what happened:
* The first click event collapsed the macro * The second click event was not fired on the macro but on document body, because after the macro collapsed the place where I clicked was in the middle of nowhere. As a result the macro was unselected. * the (logical) double click event was still fired on the macro (I guess because the target of the first click was the macro container) and thus the edit macro dialog opened * I changed the macro properties and closed the dialog. As a result the macro was duplicated. The edit dialog should have replaced the selected macro but there was no selected macro.. -----</details> -----
Therefore I propose to use a modifier key with click to collapse/expand a macro. I'm not sure which modifier key is the best. I think we should choose between Alt and Meta. The behavior would become:
* simple click to select a macro * [Alt or Meta] + simple click to toggle the collapsed and expanded state * double click to edit
I'm +1 for Alt key.
WDYT?
What about having to click in a specific area like a +/- in the top left corner to toggle the collapsed and expanded state ? This sounds a lot easier and natural for a user, most of users will never remember how to do it if it's " [Alt or Meta] + simple click".
Yes, that's what I was thinking about too. A "minimize" button at the top right of the macro displayer would be better.
Guillaume
The same from me. I configured my system so that Meta+Click drags the window, so it never reaches the browser, although the default was Alt+Click. So any KDE users won't be able to use this feature.
But this type of collision could happen with any shortcut anywhere. Take for example the meta+G shortcut that we have for page jump which collides with the 'find previous' in ff browsers. I don't think this is a real stopper unless we make sure none of our shortcuts collide with anything ever, which is virtually impossible.
The difference is that the jump feature is a nice toy which can be triggered in other ways (the link on the QuickLinks panel), and it's just a helper toy, while there are no other alternatives for Alt+Click. And our Ctrl+G shortcut still works if the document has focus, while Ctrl+G as search still works if the chrome has focus. The KDE action is beyond the browser, nothing can be done about it (except altering the KDE settings). But that is not the point, that is just a technical detail that I can live with. The problem is that it's not intuitive at all. The interface should be self-descriptive. How am I to know that I can Alt+Click to collapse/expand the macro if I don't read the documentation? If we do this, it will be limited to power users, so we could as well disable this feature if it's not intuitive and won't be used by 95% of the users. -- Sergiu Dumitriu http://purl.org/net/sergiu/
On 12/16/2009 04:36 PM, Sergiu Dumitriu wrote:
On 12/16/2009 03:16 PM, Anca Luca wrote:
On 12/16/2009 03:14 PM, Sergiu Dumitriu wrote:
On 12/16/2009 10:23 AM, Guillaume Lerouge wrote:
Hi,
On Wed, Dec 16, 2009 at 9:48 AM, Thomas Mortagne <[email protected]>wrote:
On Wed, Dec 16, 2009 at 08:30, Marius Dumitru Florea <[email protected]> wrote:
Hi devs,
Currently we have this behavior:
* simple click to select a macro * simple click to toggle between collapsed and expanded state of a previously selected macro * double click to edit the macro properties
The problem is that the double click event consists, as its name suggests, in two consecutive click events. As a consequence, when you double click to edit a macro you also toggle its visibility state. Besides being annoying, this can lead sometimes to an unexpected result:
-----<details> ----- I inserted a really long code macro (paste an entire Java source file). and them selected the macro and double clicked somewhere in the middle to edit its properties. This is what happened:
* The first click event collapsed the macro * The second click event was not fired on the macro but on document body, because after the macro collapsed the place where I clicked was in the middle of nowhere. As a result the macro was unselected. * the (logical) double click event was still fired on the macro (I guess because the target of the first click was the macro container) and thus the edit macro dialog opened * I changed the macro properties and closed the dialog. As a result the macro was duplicated. The edit dialog should have replaced the selected macro but there was no selected macro.. -----</details> -----
Therefore I propose to use a modifier key with click to collapse/expand a macro. I'm not sure which modifier key is the best. I think we should choose between Alt and Meta. The behavior would become:
* simple click to select a macro * [Alt or Meta] + simple click to toggle the collapsed and expanded state * double click to edit
I'm +1 for Alt key.
WDYT?
What about having to click in a specific area like a +/- in the top left corner to toggle the collapsed and expanded state ? This sounds a lot easier and natural for a user, most of users will never remember how to do it if it's " [Alt or Meta] + simple click".
Yes, that's what I was thinking about too. A "minimize" button at the top right of the macro displayer would be better.
Guillaume
The same from me. I configured my system so that Meta+Click drags the window, so it never reaches the browser, although the default was Alt+Click. So any KDE users won't be able to use this feature.
But this type of collision could happen with any shortcut anywhere. Take for example the meta+G shortcut that we have for page jump which collides with the 'find previous' in ff browsers. I don't think this is a real stopper unless we make sure none of our shortcuts collide with anything ever, which is virtually impossible.
The difference is that the jump feature is a nice toy which can be triggered in other ways (the link on the QuickLinks panel), and it's just a helper toy, while there are no other alternatives for Alt+Click.
And our Ctrl+G shortcut still works if the document has focus, while Ctrl+G as search still works if the chrome has focus. The KDE action is beyond the browser, nothing can be done about it (except altering the KDE settings).
From my point of view it doesn't matter that much as long as it's interfering with some shortcuts, it's still annoying.
But that is not the point,that is just a technical detail that I can live with.
Indeed.
The problem is that it's not intuitive at all. The interface should be self-descriptive. How am I to know that I can Alt+Click to collapse/expand the macro if I don't read the documentation?
You could have it in a tooltip over the macro, for example ("Alt + Click to collapse/expand".)
If we do this, it will be limited to power users, so we could as well disable this feature if it's not intuitive and won't be used by 95% of the users.
I completely agree for the intuitive aspect, as I said in my first mail. Thanks, Anca
Sergiu Dumitriu wrote:
On 12/16/2009 03:16 PM, Anca Luca wrote:
On 12/16/2009 03:14 PM, Sergiu Dumitriu wrote:
On 12/16/2009 10:23 AM, Guillaume Lerouge wrote:
Hi,
On Wed, Dec 16, 2009 at 9:48 AM, Thomas Mortagne <[email protected]>wrote:
On Wed, Dec 16, 2009 at 08:30, Marius Dumitru Florea <[email protected]> wrote:
Hi devs,
Currently we have this behavior:
* simple click to select a macro * simple click to toggle between collapsed and expanded state of a previously selected macro * double click to edit the macro properties
The problem is that the double click event consists, as its name suggests, in two consecutive click events. As a consequence, when you double click to edit a macro you also toggle its visibility state. Besides being annoying, this can lead sometimes to an unexpected result:
-----<details> ----- I inserted a really long code macro (paste an entire Java source file). and them selected the macro and double clicked somewhere in the middle to edit its properties. This is what happened:
* The first click event collapsed the macro * The second click event was not fired on the macro but on document body, because after the macro collapsed the place where I clicked was in the middle of nowhere. As a result the macro was unselected. * the (logical) double click event was still fired on the macro (I guess because the target of the first click was the macro container) and thus the edit macro dialog opened * I changed the macro properties and closed the dialog. As a result the macro was duplicated. The edit dialog should have replaced the selected macro but there was no selected macro.. -----</details> -----
Therefore I propose to use a modifier key with click to collapse/expand a macro. I'm not sure which modifier key is the best. I think we should choose between Alt and Meta. The behavior would become:
* simple click to select a macro * [Alt or Meta] + simple click to toggle the collapsed and expanded state * double click to edit
I'm +1 for Alt key.
WDYT? What about having to click in a specific area like a +/- in the top left corner to toggle the collapsed and expanded state ? This sounds a lot easier and natural for a user, most of users will never remember how to do it if it's " [Alt or Meta] + simple click".
Yes, that's what I was thinking about too. A "minimize" button at the top right of the macro displayer would be better.
Guillaume The same from me. I configured my system so that Meta+Click drags the window, so it never reaches the browser, although the default was Alt+Click. So any KDE users won't be able to use this feature.
But this type of collision could happen with any shortcut anywhere. Take for example the meta+G shortcut that we have for page jump which collides with the 'find previous' in ff browsers. I don't think this is a real stopper unless we make sure none of our shortcuts collide with anything ever, which is virtually impossible.
The difference is that the jump feature is a nice toy which can be triggered in other ways (the link on the QuickLinks panel), and it's just a helper toy, while there are no other alternatives for Alt+Click.
There is an alternative.. the Macro menu. Alt+Click is just a shortcut. Marius
And our Ctrl+G shortcut still works if the document has focus, while Ctrl+G as search still works if the chrome has focus. The KDE action is beyond the browser, nothing can be done about it (except altering the KDE settings).
But that is not the point, that is just a technical detail that I can live with. The problem is that it's not intuitive at all. The interface should be self-descriptive. How am I to know that I can Alt+Click to collapse/expand the macro if I don't read the documentation? If we do this, it will be limited to power users, so we could as well disable this feature if it's not intuitive and won't be used by 95% of the users.
On Wed, Dec 16, 2009 at 09:48, Thomas Mortagne <[email protected]> wrote:
On Wed, Dec 16, 2009 at 08:30, Marius Dumitru Florea <[email protected]> wrote:
Hi devs,
Currently we have this behavior:
* simple click to select a macro * simple click to toggle between collapsed and expanded state of a previously selected macro * double click to edit the macro properties
The problem is that the double click event consists, as its name suggests, in two consecutive click events. As a consequence, when you double click to edit a macro you also toggle its visibility state. Besides being annoying, this can lead sometimes to an unexpected result:
----- <details> ----- I inserted a really long code macro (paste an entire Java source file). and them selected the macro and double clicked somewhere in the middle to edit its properties. This is what happened:
* The first click event collapsed the macro * The second click event was not fired on the macro but on document body, because after the macro collapsed the place where I clicked was in the middle of nowhere. As a result the macro was unselected. * the (logical) double click event was still fired on the macro (I guess because the target of the first click was the macro container) and thus the edit macro dialog opened * I changed the macro properties and closed the dialog. As a result the macro was duplicated. The edit dialog should have replaced the selected macro but there was no selected macro.. ----- </details> -----
Therefore I propose to use a modifier key with click to collapse/expand a macro. I'm not sure which modifier key is the best. I think we should choose between Alt and Meta. The behavior would become:
* simple click to select a macro * [Alt or Meta] + simple click to toggle the collapsed and expanded state * double click to edit
I'm +1 for Alt key.
WDYT?
What about having to click in a specific area like a +/- in the top left corner to  toggle the collapsed and expanded state ? This sounds a lot easier and natural for a user, most of users will never remember how to do it if it's " [Alt or Meta] + simple click".
Note that I'm not against Alt or Meta (let's say +0), i just think the visual folding button is the best if it's not too painful to implement.
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
-- Thomas Mortagne
On 12/16/2009 09:30 AM, Marius Dumitru Florea wrote:
Hi devs,
Currently we have this behavior:
* simple click to select a macro * simple click to toggle between collapsed and expanded state of a previously selected macro * double click to edit the macro properties
The problem is that the double click event consists, as its name suggests, in two consecutive click events. As a consequence, when you double click to edit a macro you also toggle its visibility state. Besides being annoying, this can lead sometimes to an unexpected result:
-----<details> ----- I inserted a really long code macro (paste an entire Java source file). and them selected the macro and double clicked somewhere in the middle to edit its properties. This is what happened:
* The first click event collapsed the macro * The second click event was not fired on the macro but on document body, because after the macro collapsed the place where I clicked was in the middle of nowhere. As a result the macro was unselected. * the (logical) double click event was still fired on the macro (I guess because the target of the first click was the macro container) and thus the edit macro dialog opened * I changed the macro properties and closed the dialog. As a result the macro was duplicated. The edit dialog should have replaced the selected macro but there was no selected macro.. -----</details> -----
+1 I hit this yesterday too but didn't know what happened, I thought I did something wrong (so that my content got messed up).
Therefore I propose to use a modifier key with click to collapse/expand a macro. I'm not sure which modifier key is the best. I think we should choose between Alt and Meta. The behavior would become:
* simple click to select a macro * [Alt or Meta] + simple click to toggle the collapsed and expanded state * double click to edit
I'm +1 for Alt key.
If it's not too much trouble, a +- button could be better as it is more intuitive. If it's a pain to implement (and not really a priority right now), then Meta key could do the job too. I'd go for meta since we're using meta as a modifier mostly and, as long as it is not conflicting with anything, I'd stick with it. Happy hacking, Anca
WDYT?
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (5)
-
Anca Luca -
Guillaume Lerouge -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne