Re: [Libreoffice-ux-advise] drawing toolbar interactions

Hi everyone,

Regina in reply to Christoph:
> The status bar in Draw is unsuitable, because it is already so full with the
> drawing information (which I don't want to miss), that there is not space
> enough for an additional word.

I agree with this. I actually got the impression that our long term
goal would be to unclutter the status bar (this was a proposal for
GSoC). Seeing the exact position and size of the current drawing
object is imho more important than signalling that LibO is in "drawing
mode".

I still think, however that any button and thus activated should be in
a depressed state.
There is already this bug for the confusing alias behaviour (for
Impress only): https://bugs.freedesktop.org/show_bug.cgi?id=36796
I just opened a new bug for the Writer/Calc issue:
https://bugs.freedesktop.org/show_bug.cgi?id=36796


Regina:
> I suggest, that if a tool is in "sticky" mode, then a second click on the
> tool icon will finish this mode. Clicking a second time to switch something
> off is a often used pattern.

Agreed.


Regina:
> I do not want a changed behavior in Draw/Calc. I very often need different
> tools one after the other and going to "sticky" mode with a single click
> would result in an additional click to leave "sticky" for me.

The current Calc/Writer behaviour is that a single click keeps the
drawing tool activated.
What I don't really understand is why you think this behaviour works
so well for the Calc/Writer use case – I think most users there need
just one shape and then go back to writing/entering formulas etc.
On the whole, though, I hope the two Drawing toolbar implementations
could be united, which would probably make some more functionality
available to Writer and Calc (like rotating easily) and also might
make the codebase smaller.


Christoph:
> > So, I see two alternatives here (amongst others less attractive ones):
> >       * Separate the behavior of Draw/Impress and introduce mode changes
> >         via single click in Draw -->  will make Draw a "real" drawing
> >         application, but introduced some inconsistency within our tools

Christoph, as Regina explained, it will actually create consistency.
See above and Regina's message.


Again, Christoph:
> >       * Solve the issue by introducing a "duplicate object" feature in
> >         Draw -->  adds some clutter to the menu, but will boost
> >         efficiency for those who know

I don't get this suggestion either. To do this there is always
Copy/Paste. I'm dubious if a menu entry that did both in one step is
really useful.


Regina:
> Why "introducing a 'duplicate object' feature"? Besides simple copy and
> paste, you can drag holding down Ctrl-key or you can use Edit->Duplicate. No
> need for another "duplicate feature".

Wow, Edit > Duplicate is one crazy tool. Thanks for mentioning.



Finally, in your second message on this thread you said this about the
classic shapes:
> No. The objects have different properties. So the classical shapes
> are there intentionally and I will fight for them till the custom shapes
> have got _all_ of the properties of the classical shapes. But work on
> that is not possible before Armins CWS080 with a refactoring of the
> SdrObjects is finished.

What are these special properties? What is the status of this CWS (ie
was it nearly finished etc.)? (If you feel like this would be too
off-topic, feel free to email me personally.)

Regards,
Astron.