[xwiki-devs] [Proposal] Use a modifier key with click to collapse/expand macros inside the WYSIWYG editor
16 Dec
2009
16 Dec
'09
8:30 a.m.
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
16 Dec
16 Dec
9:48 a.m.
New subject: [xwiki-devs] [Proposal] Use a modifier key with click to collapse/expand macros inside the WYSIWYG editor
On Wed, Dec 16, 2009 at 08:30, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
10:23 a.m.
New subject: [xwiki-devs] [Proposal] Use a modifier key with click to collapse/expand macros inside the WYSIWYG editor
Hi,
On Wed, Dec 16, 2009 at 9:48 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
--
Guillaume Lerouge
Product Manager - XWiki SAS
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
On Wed, Dec 16, 2009 at 08:30, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
Yes, that's what I was thinking about too. A "minimize" button at the top
right of the macro displayer would be better.
Guillaume
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:22 a.m.
New subject: [xwiki-devs] [Proposal] Use a modifier key with click to collapse/expand macros inside the WYSIWYG editor
Guillaume Lerouge wrote:
Hi,
On Wed, Dec 16, 2009 at 9:48 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
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
On Wed, Dec 16, 2009 at 08:30, Marius Dumitru
Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
Yes, that's what I was thinking about too. A "minimize" button at the top
right of the macro displayer would be better. 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".
Guillaume
Thanks,
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3:52 p.m.
New subject: [xwiki-devs] [Proposal] Use a modifier key with click to collapse/expand macros inside the WYSIWYG editor
On 12/16/2009 11:22 AM, Marius Dumitru Florea wrote:
Guillaume Lerouge wrote:
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/
Hi,
On Wed, Dec 16, 2009 at 9:48 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
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. On Wed, Dec 16, 2009 at 08:30, Marius Dumitru
Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
Yes, that's what I was thinking about too. A "minimize" button at the top
right of the macro displayer would be better. 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".
4:30 p.m.
New subject: [xwiki-devs] [Proposal] Use a modifier key with click to collapse/expand macros inside the WYSIWYG editor
Sergiu Dumitriu wrote:
On 12/16/2009 11:22 AM, Marius Dumitru Florea wrote:
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.
Guillaume Lerouge wrote:
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?
Hi,
On Wed, Dec 16, 2009 at 9:48 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
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. On Wed, Dec 16, 2009 at 08:30, Marius Dumitru
Florea
<mariusdumitru.florea(a)xwiki.com> 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. 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
6:22 p.m.
New subject: [xwiki-devs] [Proposal] Use a modifier key with click to collapse/expand macros inside the WYSIWYG editor
On 12/16/2009 04:30 PM, Marius Dumitru Florea wrote:
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/
Sergiu Dumitriu wrote:
OK, agreed. I forgot about the Macro menu, so since there is an
alternative, +1 for the shortcut. The tooltip idea is nice, too.
On 12/16/2009 11:22 AM, Marius Dumitru Florea
wrote:
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. Guillaume Lerouge wrote:
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?
Hi,
On Wed, Dec 16, 2009 at 9:48 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
> On Wed, Dec 16, 2009 at 08:30, Marius Dumitru Florea
> <mariusdumitru.florea(a)xwiki.com> 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. 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.
2:14 p.m.
New subject: [xwiki-devs] [Proposal] Use a modifier key with click to collapse/expand macros inside the WYSIWYG editor
On 12/16/2009 10:23 AM, Guillaume Lerouge wrote:
Hi,
On Wed, Dec 16, 2009 at 9:48 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
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 Wed, Dec 16, 2009 at 08:30, Marius Dumitru
Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
Yes, that's what I was thinking about too. A "minimize" button at the top
right of the macro displayer would be better.
Guillaume 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".
3:16 p.m.
New subject: [xwiki-devs] [Proposal] Use a modifier key with click to collapse/expand macros inside the WYSIWYG editor
On 12/16/2009 03:14 PM, Sergiu Dumitriu wrote:
On 12/16/2009 10:23 AM, Guillaume Lerouge wrote:
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
Hi,
On Wed, Dec 16, 2009 at 9:48 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
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.
On Wed, Dec 16, 2009 at 08:30, Marius Dumitru
Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
Yes, that's what I was thinking about too. A "minimize" button at the top
right of the macro displayer would be better.
Guillaume 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".
3:36 p.m.
New subject: [xwiki-devs] [Proposal] Use a modifier key with click to collapse/expand macros inside the WYSIWYG editor
On 12/16/2009 03:16 PM, Anca Luca wrote:
On 12/16/2009 03:14 PM, Sergiu Dumitriu wrote:
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 10:23 AM, Guillaume Lerouge wrote:
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.
Hi,
On Wed, Dec 16, 2009 at 9:48 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
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.
On Wed, Dec 16, 2009 at 08:30, Marius Dumitru
Florea
<mariusdumitru.florea(a)xwiki.com> 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
3:50 p.m.
New subject: [xwiki-devs] [Proposal] Use a modifier key with click to collapse/expand macros inside the WYSIWYG editor
On 12/16/2009 04:36 PM, Sergiu Dumitriu wrote:
On 12/16/2009 03:16 PM, Anca Luca wrote:
From my point of view it doesn't matter that much as long as it's interfering
with some shortcuts, it's still annoying.
On 12/16/2009 03:14 PM, Sergiu Dumitriu wrote:
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). On 12/16/2009 10:23 AM, Guillaume Lerouge wrote:
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.
Hi,
On Wed, Dec 16, 2009 at 9:48 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
> On Wed, Dec 16, 2009 at 08:30, Marius Dumitru Florea
> <mariusdumitru.florea(a)xwiki.com> 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 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
4:07 p.m.
New subject: [xwiki-devs] [Proposal] Use a modifier key with click to collapse/expand macros inside the WYSIWYG editor
Sergiu Dumitriu wrote:
On 12/16/2009 03:16 PM, Anca Luca wrote:
There is an alternative.. the Macro menu. Alt+Click is just a shortcut.
Marius
On 12/16/2009 03:14 PM, Sergiu Dumitriu wrote:
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. On 12/16/2009 10:23 AM, Guillaume Lerouge wrote:
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.
Hi,
On Wed, Dec 16, 2009 at 9:48 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
> On Wed, Dec 16, 2009 at 08:30, Marius Dumitru Florea
> <mariusdumitru.florea(a)xwiki.com> 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.
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.
10:44 a.m.
New subject: [xwiki-devs] [Proposal] Use a modifier key with click to collapse/expand macros inside the WYSIWYG editor
On Wed, Dec 16, 2009 at 09:48, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
--
Thomas Mortagne
On Wed, Dec 16, 2009 at 08:30, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
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.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
10:35 a.m.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5388
days inactive
5388
days old
13 comments
5 participants
participants (5)
-
Anca Luca -
Guillaume Lerouge -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne