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