On 12/16/2009 04:30 PM, Marius Dumitru Florea wrote: > 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.
OK, agreed. I forgot about the Macro menu, so since there is an alternative, +1 for the shortcut. The tooltip idea is nice, too. >> 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. 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/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
