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 :)

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]
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.

-                    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 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 ! :-)

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 )

@federico@gnome.org:
Did you present your patch on <libreoffice@lists.freedesktop.org>?

@Federico Mena-Quintero:
Did you present your patch on <libreoffice@lists.freedesktop.org>?

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).

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.)

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.

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.

Cheers,
  Kevin

@Federico Mena-Quintero

any progress on this issue? are you still working on it or should we reset assignation?

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.

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.