The .uno:Save command is bound to multiple actions GUI and keyboard, the .uno action for the split button on the Standard toolbar would need the adjustment not the other way around.

That said, I see little need for providing alternative to the new stateful split button for toolbar customization--and do not want to see the Standard toolbar visible buttons list cluttered with additional inactive buttons.  

IMHO current UI Menu/accelerator and general/module specific keyboard shortcut actions remain sufficient.

(In reply to V Stuart Foote from comment #1)
> The .uno:Save command is bound to multiple actions GUI and keyboard, the
> .uno action for the split button on the Standard toolbar would need the
> adjustment not the other way around.
> 
> That said, I see little need for providing alternative to the new stateful
> split button for toolbar customization--and do not want to see the Standard
> toolbar visible buttons list cluttered with additional inactive buttons.  
> 
> IMHO current UI Menu/accelerator and general/module specific keyboard
> shortcut actions remain sufficient.

The single action button need not be visible on the basic standard toolbar, but available as an option when customising the toolbar - that way it's there if people want it instead.

(In reply to V Stuart Foote from comment #1)
> ....  
> 
> IMHO current UI Menu/accelerator and general/module specific keyboard
> shortcut actions remain sufficient.

I respectfully disagree with you. 
there are many users that would prefer just having the save command without the dropdown, so allowing a free choice thanks to an alternative UNO command would be a bless for them and would not cause any harm to the others who like the split button.

when you say "IMHO" you are clearly only considering you tastes only and not other's people issues.

If you don't need an option, don't use it but, please let other people be free to use it.

for example "IMHO" the sidebar is useless, I never use it and all buttons and menus from the regular UI are sufficient to me...

anyway, I'm not against the implementation of the sidebar... if there's people who like it they are free to use it... I just disabled it... but this is what "customization" is all about.


in the meantime I just recorder a simple macro that can be assigned to a custom button with a custom icon in the toolbar just to have a single save button without dropdown menu.

only issue is that the icon would not change it's look according to the document change.

maybe with some more tweaking an extension with greyed button effect could be created.

anyway here's the code:



sub Save
rem ----------------------------------------------------------------------
rem define variables
dim document   as object
dim dispatcher as object
rem ----------------------------------------------------------------------
rem get access to the document
document   = ThisComponent.CurrentController.Frame
dispatcher = createUnoService("com.sun.star.frame.DispatchHelper")

rem ----------------------------------------------------------------------
dispatcher.executeDispatch(document, ".uno:Save", "", 0, Array())

end sub

The change was made in this patch. https://gerrit.libreoffice.org/#/c/20079/

Thanks Jay (and Maxim), verified that an Tools -> Options -> Advanced "Expert Configuration" session searching for "SaveToolbarController"

and edit the "controller" string replacing

"com.sun.star.comp.framework.SaveToolbarController"

with

"com.sun.star.comp.framework.GenericPopupToolbarController"

restores the non-split button behavior to the Toolbar "Save" button.

Reverse steps to restore the Split button.


Given that, is there still a need for an additional .uno command? I guess maybe to support customization, and also for the single toolbar implementation.

(In reply to V Stuart Foote from comment #5)
> Thanks Jay (and Maxim), verified that an Tools -> Options -> Advanced
> "Expert Configuration" session searching for "SaveToolbarController"
> 
> and edit the "controller" string replacing
> 
> "com.sun.star.comp.framework.SaveToolbarController"
> 
> with
> 
> "com.sun.star.comp.framework.GenericPopupToolbarController"
> 
> restores the non-split button behavior to the Toolbar "Save" button.
> 
> Reverse steps to restore the Split button.
> 
> 
> Given that, is there still a need for an additional .uno command? I guess
> maybe to support customization, and also for the single toolbar
> implementation.


Thank you, and thanks Jay,

I've implemented that option and am now fully operational, as long as it doesn't get replaced in a future upgrade and I remember to make the same change on any future installation on other system.

However, this only helps people who are tech savvy enough to come here and look for an answer and also happy to work in that part of the system. Thus I think it still needs someway for a person of less technical knowledge to be able to find and use.

For whoever is going to work on this - beware that just "moving the split button to .uno:SaveExt" isn't going to work, as the underlying code will need to be (partially) rewritten to accommodate this change (mainly in wrt. to dbaccess part). And the "singular command" will also need to show modified/unmodified states somehow - which means that it will need to share the same code with the split button anyway (unless the design team will change it's mind, and propose reverting the "always enabled save" thing).

BTW given that a "singular command" is supposed to be an _alternative_ to the split button (i.e. users who prefer it will put it on toolbar _instead_ of the split button, no one will use both probably), why not implement it as a checkbox in configuration instead of a separate command? Implementing it that way will cause much less headache, and won't break the setup of users who do like the split button, but had customized their toolbar (so it contains .uno:Save). Any objections to this?

(In reply to Yousuf (Jay) Philips from comment #4)
> The change was made in this patch. https://gerrit.libreoffice.org/#/c/20079/
No it's not. It was made a way before in https://cgit.freedesktop.org/libreoffice/core/commit/?id=225f2ebcda079be170831552a764d884e0b55249

(In reply to Maxim Monastirsky from comment #7)
> Any objections to this?

The state indication was changed since the disabled split button gives no access to the hidden function. And the various save operations were integrated into one button because of streamlining the toolbar. This behavior and layout is supposed to be the default.

For accessibility reasons (and also individualization purpose) the option to have the old Save functionality was requested. Although we think the majority of users is happy with the default plus the shortcut Ctrl+S. So the alternative should be not one of the mutlitude of settings we have but "hidden" in the customization dialog.

We should also keep in mind that "Save to Remote Server" would be not available when the user places the new solitude Save and Save As onto the toolbar. Meaning the alternative is of less functionality.

(In reply to Maxim Monastirsky from comment #7)
> BTW given that a "singular command" is supposed to be an _alternative_ to
> the split button (i.e. users who prefer it will put it on toolbar _instead_
> of the split button, no one will use both probably), why not implement it as
> a checkbox in configuration instead of a separate command? Implementing it
> that way will cause much less headache, and won't break the setup of users
> who do like the split button, but had customized their toolbar (so it
> contains .uno:Save). Any objections to this?

There are times when both uno commands would be useful at the same time, like for example the Save split being in the standard toolbar and the standard Save in the helpauthoring toolbar.

(In reply to Maxim Monastirsky from comment #8)
> No it's not. It was made a way before in
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=225f2ebcda079be170831552a764d884e0b55249

Sorry my bad. :D I was pointing to that gerrit patch as it is where i suggested that we have two uno commands for the standard and split.

(In reply to Heiko Tietze from comment #9)
> (In reply to Maxim Monastirsky from comment #7)
> > Any objections to this?
> 
> The state indication was changed since the disabled split button gives no
> access to the hidden function. And the various save operations were
> integrated into one button because of streamlining the toolbar. This
> behavior and layout is supposed to be the default.
> 
> For accessibility reasons (and also individualization purpose) the option to
> have the old Save functionality was requested. Although we think the
> majority of users is happy with the default plus the shortcut Ctrl+S. So the
> alternative should be not one of the mutlitude of settings we have but
> "hidden" in the customization dialog.
> 
> We should also keep in mind that "Save to Remote Server" would be not
> available when the user places the new solitude Save and Save As onto the
> toolbar. Meaning the alternative is of less functionality.

The change back is only less functionality if you actually use the functionality added in with the split button. I can see how this is better on a mobile device where you will be saving to a remote server, but I use a desktop and everyone I personally know uses a desktop for all their word processing work. They don't use Libre Office on any mobile device smaller than full blown laptop computer, and then they save to the computer and not remotely. 

Now I only know thirty or forty users, all people I've talked into switching to Libre Office after they complained too often about the WS Word Ribbon and how useless it is for a desktop system. We all customise our toolbars and not one of us has the 'Save as' button on the toolbar, but we all have the 'Save' button to save the work in progress.

From my perspective, if I can get the choice of which button to use, and set it either a an install set up option or a toolbar customise option, I'll be happy. I've got it working (sort of) using the Expert Configuration process, but that is NOT something you should be suggesting to the general users to do. Many wouldn't understand what you're saying to do in the configuration area, despite having experience in customising toolbars.

As to toolbar streamlining, if you look at the images I posted with the original bug report, you'll see I combined the Standard toolbar and the Format toolbar and still have less icons than the original Standard toolbar, because I customised out everything I don't use at least once a month.

(In reply to Heiko Tietze from comment #9)
> ....
> 
> We should also keep in mind that "Save to Remote Server" would be not
> available when the user places the new solitude Save and Save As onto the
> toolbar. Meaning the alternative is of less functionality.

please consider that there are users like me who never use Remote server saving.
so in this scenario there's no loss of functionality with the "solitude" save 

in other words...
if you need remote saving, the split button is a bless.
if you don't need remote saving, the split button is an annoyance

(In reply to Ernest Bywater from comment #11)
> The change back is only less functionality if you actually use the
> functionality added in with the split button. I can see how this is better
> on a mobile device where you will be saving to a remote server, but I use a
> desktop and everyone I personally know uses a desktop for all their word
> processing work. They don't use Libre Office on any mobile device smaller
> than full blown laptop computer, and then they save to the computer and not
> remotely. 

(In reply to tommy27 from comment #12)
> please consider that there are users like me who never use Remote server
> saving.
> so in this scenario there's no loss of functionality with the "solitude"
> save 
> 
> in other words...
> if you need remote saving, the split button is a bless.
> if you don't need remote saving, the split button is an annoyance

The split button has a highly used feature that is used to save files locally, Save As. The Save As button was previously visible in the standard toolbar because of its high usage, which was only accessible in the menu bar.

(In reply to Yousuf (Jay) Philips from comment #13)

> The split button has a highly used feature that is used to save files
> locally, Save As. The Save As button was previously visible in the standard
> toolbar because of its high usage, which was only accessible in the menu bar.

This may be true for some people. However, my limited empirical data is the remote save would get used 1% of the time, and the save as about 5% of the time.

In my case I write stories. I have a 16 KB story layout file I use as a template. When I start a story I open that file, use the menu to 'save as' the new story file name. Then commence to write the story, using the 'save' to save the file every now and then, even though I have it set to save every 5 minutes. In the course of a typical story of around 200 KB I'll use the save button about 1,000 times. Later I'll do an edit. Then I send it to an editor, incorporate his changes, repeat for the 2nd and 3rd editors. By the time I have the story ready for publication I'll have used the 'save' button between 4,000 to 5,000 times on that story over a four or five week period. I usually work on five or six stories at a time. In the course of a month I'll use the 'save' button around 50,000 times. Part of this is because I use the 'save' button after every edit change made in the middle of the story.

I hope this helps you to understand why I see the way the button used to work is so important to me. I use that button several times more often than any other icon on the toolbar. After it the italics, bold, cut, and paste are close together for the next four places. The style settings on the sidebar get a hell of a work out too.

I forgot to include, before anyone tells me to use Ctrl-S again, please note, like a lot of older people I have some joint issues. I also use a small keyboard to reduce hand and fingre movements. My A-power keyboard doesn't have a number pad because I don't do financial entry stuff now (haven't for over a decade), so i don't need that. The keyboard is 295 mm x 150 mm (11.5 x 6.0 inches) in size, and the distance between the Ctrl button and the S button is 50 mm (2 inch) at a 45 degree angle, and these is only the one Ctrl button on the keyboard. There is absolutely NO easy way to hit Ctrl-S with the one hand on this keyboard. Which is why using the mouse to use the 'save' button is easier and quicker for me.

I may not be the most common garden variety user, but since the company sells millions of this keyboard each year, I'm not alone in using such a small keyboard.

(In reply to Ernest Bywater from comment #14)
> This may be true for some people. However, my limited empirical data is the
> remote save would get used 1% of the time, and the save as about 5% of the
> time.

As libreoffice currently is limited to only saving remotely to Google Drive, yes a limited amount of users would use that feature as they likely have their files in dropbox, onedrive, etc. With Save As, statistical data is available on how much it is used and it is way over 5%.

We dont need to turn this bug report into a huge discussion as the previous one was. We decided to bring back the old toolbar button and await a developer to work on it.

the see also for 98730 is sufficient it does not block this

@Jay
it seems to me you are trying to convince me and Ernest that we should like the new split button. as we already told multiple times, we don't like that and we have more than valid reasons not to like it.

this button can be very useful for some users (and I'm happy they can use it) but annoying for others... but it seems that you don't want to understand why some people don't find it useful.

anyway after discovering that an advanced setting can be used to restore the old button, that's enough for me and I'm happy with it. the greyed out visual hint is gone, but I can live even without it...

the "take home point" I'd like the UX-team is going to learn from this is that any UI change should consider likers and haters as well... 

any new feature is always welcome, but I think it's always better to leave the door open for the user that should always be free to decide whether to adopt the new UI feature or stick with the previous one

(In reply to Yousuf (Jay) Philips from comment #16)
> ....
> 
> We dont need to turn this bug report into a huge discussion as the previous
> one was. 
> ....

I respectfully disagree with you. Discussion is essential to compare different users needs and maybe learn something from each other.

Maxim Monastirsky committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ae00a95ea458a0328d7b12d25c231e9f4ac8eed8

tdf#98745 Optional save button without the dropdown

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

thanks Maxim,
I'll certainly test it once a daily build will be available.

VERIFIED FIXED in 5.2.0.0.alpha0+
Build ID: 379fb96dbd5ce0fdb0aaf5244d50583dc13d7611
CPU Threads: 4; OS Version: Windows 6.29; UI Render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2016-03-26_14:01:39
Locale: it-IT (it_IT)

any chance this can be backported into next 5.1.3 release?