Bug 39268 - UI: Drawing tools should not switch back to Selection tool
Summary: UI: Drawing tools should not switch back to Selection tool
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
3.3.1 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
: 42544 (view as bug list)
Depends on:
Blocks: Draw-UX
  Show dependency treegraph
 
Reported: 2011-07-15 11:02 UTC by Federico Mena-Quintero
Modified: 2019-04-26 16:43 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
bfo39268-dont-switch-to-select-tool.diff (28.84 KB, patch)
2011-07-15 13:54 UTC, Federico Mena-Quintero
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Federico Mena-Quintero 2011-07-15 11:02:04 UTC
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. ?

(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.
Comment 1 Federico Mena-Quintero 2011-07-15 11:53:19 UTC
It seems that most tools (impress/sd/source/ui/func/fucon*.cxx) have a snippet like this in their ::MouseButtonUp() methods:

    if (!bPermanent)
        mpViewShell->GetViewFrame()->GetDispatcher()->Execute(SID_OBJECT_SELECT, SFX_CALLMODE_ASYNCHRON);


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;
            }

            GetCurrentFunction()->Deactivate();
        }

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 :)
Comment 2 Federico Mena-Quintero 2011-07-15 12:13:27 UTC
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.
Comment 3 Federico Mena-Quintero 2011-07-15 13:54:05 UTC
Created attachment 49163 [details]
bfo39268-dont-switch-to-select-tool.diff

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.
Comment 4 Felix Möller 2011-07-16 00:05:13 UTC
-                    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
Comment 5 Federico Mena-Quintero 2011-07-16 14:41:23 UTC
(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 :)
Comment 6 Michael Meeks 2011-07-20 05:12:01 UTC
Patches in bugzilla are somewhat sucky, in general we prefer E-mail to libreoffice@lists.freedesktop.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 ! :-)
Comment 7 Federico Mena-Quintero 2011-07-28 09:42:05 UTC
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 )
Comment 8 Björn Michaelsen 2011-12-23 12:26:44 UTC Comment hidden (obsolete)
Comment 9 Rainer Bielefeld Retired 2012-01-06 08:45:26 UTC
@federico@gnome.org:
Did you present your patch on <libreoffice@lists.freedesktop.org>?
Comment 10 Rainer Bielefeld Retired 2012-01-25 23:09:28 UTC
@Federico Mena-Quintero:
Did you present your patch on <libreoffice@lists.freedesktop.org>?
Comment 11 Stefan Knorr (astron) 2012-01-25 23:24:00 UTC
Hi Rainer,

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.
See here: 
http://lists.freedesktop.org/archives/libreoffice-ux-advise/2011-July/000136.html

http://lists.freedesktop.org/archives/libreoffice-ux-advise/2011-August/thread.html

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).
Comment 12 Federico Mena-Quintero 2012-01-27 09:26:57 UTC
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.)
Comment 13 Stefan Knorr (astron) 2012-02-06 03:09:53 UTC
Hi Federico,

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.
Comment 14 Thorsten Behrens (allotropia) 2012-07-25 19:00:40 UTC
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?
Comment 15 Kevin Ernst 2012-09-15 21:35:03 UTC
(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.

Cheers,
  Kevin
Comment 16 tommy27 2013-09-29 07:10:51 UTC
@Federico Mena-Quintero

any progress on this issue? are you still working on it or should we reset assignation?
Comment 17 QA Administrators 2015-07-18 17:43:03 UTC Comment hidden (obsolete)
Comment 18 tommy27 2015-07-20 08:55:52 UTC
still reproducible with LibO 4.4.5.1 and 5.1.0.0.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.
Comment 19 MarjaE 2015-09-17 17:41:23 UTC
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.
Comment 20 Heiko Tietze 2016-05-25 15:13:10 UTC
*** Bug 42544 has been marked as a duplicate of this bug. ***
Comment 21 Heiko Tietze 2016-05-25 15:15:19 UTC
Isn't this an EASYHACK since we have a patch?
Comment 22 Regina Henschel 2016-05-25 18:06:10 UTC
This change is controversial, see comment 19. I too do not like such behavior.
Comment 23 Heiko Tietze 2016-05-26 09:55:17 UTC
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?
Comment 24 V Stuart Foote 2016-05-26 22:26:18 UTC
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.
Comment 25 Yousuf Philips (jay) (retired) 2016-10-22 13:21:31 UTC
(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.
Comment 26 Marilyn T. Johnson 2019-04-26 16:43:18 UTC Comment hidden (spam)