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
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
