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