I've been thinking of why drawing in LibreOffice feels much more cumbersome than, say, Inkscape.
The basic thing is that in LO, drawing works like this:
1. Select a drawing tool (line, arrow, rectangle, etc.)
2. Draw a shape by press-drag-release.
(3) is the problem: after drawing with some tools, as soon as you release the mouse button, you get taken back to the Selection tool - you can't draw another shape of the same kind. With other tools, *sometimes* they remain in the same tool, and sometimes they switch back to the Selection tool.
For example, the Line and Arrow tools always seem to take you back to the Selection tool. This makes it hard to draw some shapes that you later want to connect with arrows: you draw and arrow and you have to click *again* on the Arrow tool, draw another arrow, click *again* on the Arrow tool...
The Rectangle tool seems to switch back to selection inconsistently. Sometimes it does and sometimes it doesn't, and I haven't been able to find why it may decide differently each time.
As a result, it will often happen that I draw a shape, and then I want to draw another similar shape but instead I inadvertently start dragging an existing object (because I got switched back to the Selection tool, which drags objects to a different location).
In contrast, Inkscape keeps you on the same tool once you select it. In your mind it is always clear what is going to happen next: draw a new shape of the same kind, or edit the shape you just drew via its handles.
Inkscape's actual behavior is like this:
1. You pick a drawing tool.
2. If you press-drag-release , you will draw a shape. The current tool stays put.
3. Once you draw a shape, its handles appear. You can drag them to edit the shape that you just drew.
4. If you are on a drawing tool but just press-release without dragging (i.e. click on the canvas), you'll select the object under the cursor.
LibreOffice's drawing mode would be much more usable if it followed this predictable behavior, instead of using its current unpredictable one.
It seems that most tools (impress/sd/source/ui/func/fucon*.cxx) have a snippet like this in their ::MouseButtonUp() methods:
In turn, that "bPermanent" comes from an argument passed to ::Create().
As far as I can tell, that argument comes from impress/sd/source/ui/view/drviewse.cxx - it calls various things like
SetCurrentFunction( FuConstructArc::Create( this, GetActiveWindow(), mpDrawView, GetDoc(), rReq, bPermanent) );
depending on the current tool.
That bPermanent comes from this mysterious bit from DrawViewShell::FuPermanent():
sal_Bool bPermanent = sal_False;
... much later ...
if( HasCurrentFunction() )
nOldSId = GetCurrentFunction()->GetSlotID();
if (nOldSId == nSId ||
((nOldSId == SID_TEXTEDIT || nOldSId == SID_ATTR_CHAR || nOldSId == SID_TEXT_FITTOSIZE ||
nOldSId == SID_ATTR_CHAR_VERTICAL || nOldSId == SID_TEXT_FITTOSIZE_VERTICAL) &&
(nSId == SID_TEXTEDIT || nSId == SID_ATTR_CHAR || nSId == SID_TEXT_FITTOSIZE ||
nSId == SID_ATTR_CHAR_VERTICAL || nSId == SID_TEXT_FITTOSIZE_VERTICAL )))
bPermanent = sal_True;
I have no idea what the purpose of that is.
By the way, just by chance I found that if you *click twice* on a tool's item in the toolbar, rather than just single-click it, the tool indeed does *not* change back to the Selection tool once you draw something. It doesn't have to be a fast double-click; simply clicking twice on the tool item will do it. This seems un-idempotent enough to be a bug :)
In the "draw objects;adding/editing/copying" node in the Help, we have this gem:
"1. To draw multiple objects of the same type, double-click the icon."
So maybe that's where the bPermanent stuff comes from. This is overkill given that we could use Inkscape's much simpler scheme.
Created attachment 49163 [details]
This is a patch in progress.
So far it removes the code that switches back to the Selection tool after drawing with another tool, and cleans up the associated machinery.
I still have to ensure that when you are on a drawing tool, just clicking on an existing object will select it (e.g. a simple press-release, not press-drag-release that would create a new shape in the current tool).
I also have to remove the corresponding bit from the Help file.
- else if ( nSlotId != SID_TEXTEDIT &&
- (bPermanent || !bFirstObjCreated) )
+ else if ( nSlotId != SID_TEXTEDIT && !bFirstObjCreated )
is that right?
The assumption is that now bPermanent==TRUE always, so we can simplify
the boolean tests that involve that field.
nSlotId != SID_TEXTEDIT && (bPermanent || !bFirstObjCreated)
nSlotId != SID_TEXTEDIT && (TRUE || !bFirstObjCreated)
nSlotId != SID_TEXTEDIT && (TRUE)
nSlotId != SID_TEXTEDIT
(In reply to comment #4)
> - else if ( nSlotId != SID_TEXTEDIT &&
> - (bPermanent || !bFirstObjCreated) )
> + else if ( nSlotId != SID_TEXTEDIT && !bFirstObjCreated )
> is that right?
Oops, you are correct. I'll fix it. Thanks for the quick review :)
Patches in bugzilla are somewhat sucky, in general we prefer E-mail to firstname.lastname@example.org [ no subscription required ;-] we need to prod the ux advise list on this I guess, let me do that.
Having said all that - great to have a new patch from you Federico ! :-)
One thing I forgot to mention - in Inkscape, hitting the Spacebar toggles you between the Selection tool and the current drawing tool.
Pressing Esc keeps the current tool, but deselects everything.
(The full reference is at http://inkscape.org/doc/keys048.html )
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Did you present your patch on <email@example.com>?
Did you present your patch on <firstname.lastname@example.org>?
Federico's patch wasn't complete yet, but he took it to the ML, from where Michael took it to UX-advise and (sadly, I think) some comments there seem to have discouraged Federico from further development.
As is, it is probably not desirable to have this patch in LibreOffice (maybe on a new feature branch, if Federico does want to take this up again).
Apologies for dropping the ball on this. I didn't get discouraged; it's just that Life Happened and I didn't get much time to keep working on this :)
Thanks for linking to both the July and August parts of the mailing list thread! I wasn't aware of the August part - silly mailman (I'm not subscribed to that list; maybe I should, if I intend to finish this...).
I'll try to post a quick summary of the thread:
* There is a bug/inconsistency/angst about "old" drawing tools vs. new shapes. Apparently not all of the new ones have the features that one would expect. I don't know the details of this, but it shouldn't interfere with making the drawing workflow simpler.
* There is discussion about how to indicate that one is in a certain mode. My point is that you don't really have modes; a tool *is* the mode in which you are in, and that's it. You are either in the selection tool or in a drawing tool, or perhaps in a tweak-the-vertices tool, but each tool doesn't have any sub-modes. We can indicate this very clearly with the mouse cursor: arrow for selection, crosshair for drawing, and maybe a finer shape of arrow for tweaking vertices.
* Differences in behavior between the "drawing" programs (Draw, Impress) and the "other" programs (Writer, Calc). To be honest, I haven't used the drawing tools very much in those other programs; I almost always draw something in Draw or Impress and the cut&paste it to the others. I'll need to see how things feel right now and how they would feel if my proposal were implemented.
* As for the behavior of the toolbar buttons, the fundamental thing is for the current tool to be *visible* as *selected*, and nothing more. This doesn't happen consistently right now for the sub-shapes that can be accessed with a long click.
* I haven't thought very much about the implications of the clicking-on-a-selected-shape-lets-you-add-text behavior. It seems to get in the way when you want to draw overlapping shapes. I haven't studied the code closely enough, but maybe this can be resolved by turning on text insertion on mouse-release, only if the mouse didn't move sinde the mouse-press, or something like that. Again, need to test the behavior more carefully.
* Regina had some concerns about increasing the number of clicks when switching among tools. You already have to click on the tool you want to use next, so I don't see how this would increment the clicks needed. (Personally I don't see "number of clicks" as much of a problem; they are only a problem if the program confuses you so that you need to click again to "really" set a mode that you think you were in, but in fact weren't.)
good to hear, it's only life that happened.
Okay, about your comments, generally, I agree with your opinions with the following additions to be made:
* Modes: again, I see that similarly. If necessary, the new recould be fixed by a follow-up patch.
* Different applications: these toolbars had different implementations, nevertheless, they should (I think) all feel consistent, so it would good if you could make patches for both implementations. (But Regina and Christoph saw this differently.)
* Add text only after mouse-down: sounds like a clever implementation! I hope it would work as well as it sounds to me.
So it looks like Federico is moving ahead with this - I take the liberty to assign you the bug & push further.
Also removing NEEDINFO keyword, or is there anything left doing for unlocking this?
Can you poke the list again when this is nearing completion, so someone can stick the patches into master?
(In reply to comment #1)
> By the way, just by chance I found that if you *click twice* on a tool's item
> in the toolbar, rather than just single-click it, the tool indeed does *not*
> change back to the Selection tool once you draw something. It doesn't have to
> be a fast double-click; simply clicking twice on the tool item will do it.
> This seems un-idempotent enough to be a bug :)
One comment on this: this could very much BE desirable behavior, IF the UI made it obvious enough that the selected tool was "locked" in the way you describe. Which is, I think the real problem to be solved. Dunno how easy this would be to implement for LO, but perhaps a bold outline around the selected tool and a "<Tool Name> (locked)" in the tooltip?
Being a somewhat-proficient Inkscape user, I do appreciate Inkscape's way of managing this problem (especially the space bar toggle described in another comment here). However, I've seen the double-click-to-lock implemented in at least one other application that I frequently use (PDFpen for OS X), and I think it's quite nice, PROVIDED that the toolbar gives you appropriate visual feedback. The means by which PDFpen does this is a different color highlight for the selected (and locked) tool. I seem to recall other graphics programs' UIs putting a small square (or perhaps a triangle) in one corner of the tool palette button, as an alternative.
This double-click-to-lock behavior may have been inherited from some much older tools (for all I know, Aldus Freehand or something), so it may in fact be more familiar to some users than Inkscape's behavior. That's just speculation, but perhaps KEEPING this behavior in LO, as is, and ALSO implementing the space-to-switch behavior from Inkscape is the optimal solution in the end?
Not to throw a wrench in Federico's patch, but just my attempt to offer a slightly different perspective. Indeed, the behavior of the line & shape drawing tools *is* currently quite squirrelly in LO (as late as 3.6.1), so any improvement to that code whatsoever will surely benefit heavy users of Draw.
any progress on this issue? are you still working on it or should we reset assignation?
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later): https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)
2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword
Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa
Thank you for your help!
-- The LibreOffice QA Team This NEW Message was generated on: 2015-07-18
still reproducible with LibO 220.127.116.11 and 18.104.22.168.alpha1+ (x64)
Build ID: 449d272daf5e99f039cdfdd25f020bd798fb9e1d
TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2015-07-08_08:13:06
Locale: it-IT (it_IT)
I suspect it has always been like that also in the OOo era.
Clumsy user here.
If I draw something, the first thing I need to do is either risize it or move it where it should be. So I need to go to the selection tool, and find it much harder to work if it adds a new object when I'm trying to fix the first object.
Spacebar would be a nuisance.
Double-click with indication should work with either workflow, as long as users know about it.
*** Bug 42544 has been marked as a duplicate of this bug. ***
Isn't this an EASYHACK since we have a patch?
This change is controversial, see comment 19. I too do not like such behavior.
My first idea was the same as in comment 7 to replicate the Inkscape behavior. But actually we have an own mechanism, lock by double-click (well known for clone formatting, for example), which is also pointed out in comment 15. And surprise, surprise it works right now. So I'd close this bug as WORKSFORME. Objections?
Draw tool is "locked" active with a double click on any of the tool button widgets in the Drawing toolbar, and the button indicates it has been selected.
On completion of the object a single click on the document canvas completes use of the drawing tool and reverts to selection mode.
So single click -> create single object vs. a double click -> create multiple objects using the Drawing toolbar buttons seems correctly implemented.
Not sure when it was done, but agree WFM.
(In reply to MarjaE from comment #19)
> If I draw something, the first thing I need to do is either risize it or
> move it where it should be. So I need to go to the selection tool, and find
> it much harder to work if it adds a new object when I'm trying to fix the
> first object.
This isnt accurate. While in draw mode, you can still resize and move an object, as the draw cursor disappears when these operations are available.
(In reply to Heiko Tietze from comment #23)
> But actually we have an own mechanism, lock by double-click (well
> known for clone formatting, for example), which is also pointed out in
> comment 15.
Discoverability of double-click to lock-in draw mode isnt something a novice user will discover, the same goes for clone formatting. So similar to my comment in bug 90748 comment 8, i would be in favour of only Draw having this single-click lock-in draw mode and it removed from writer and calc.
Similar bugs arise in physical tools, for example, for wood processing. It is good that there are similar reviews of the company as https://thecozyholic.com/best-wood-lathe focus on the quality product and makes an extensive review in order to avoid bugs when working with wood.