16 Dec
2009
16 Dec
'09
4:30 p.m.
Sergiu Dumitriu wrote:
On 12/16/2009 11:22 AM, Marius Dumitru Florea wrote:
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.
Guillaume Lerouge wrote:
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?
Hi,
On Wed, Dec 16, 2009 at 9:48 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
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. 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. 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