16 Dec
2009
16 Dec
'09
4:07 p.m.
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.