search

phase1geo / Minder

Mind-mapping application for Elementary OS
GNU General Public License v3.0
1.02k stars 67 forks source link

Visual cue to indicate autosaving #246

Open dagelf opened 3 years ago

dagelf commented 3 years ago

No save button is unsettling to old hands... a visual cue to indicate auto-saving would go a long way to comfort those.

phase1geo commented 3 years ago

Map changes cause automatic file saving. This is not done on a periodical basis so adding this information would be visual noise. According to the elementary OS HIG, all applications should auto-save state information such that whenever an application is started it should resume the same state.

dagelf commented 3 years ago

I like that philosophy... and am thinking how to do this without "visual noise".

The elementary OS guidance applies... however a problem with this is that if people get used to things autosaving on Elementary, they are bound to lose data when using other apps that do not autosave, assuming that everything does.

Seeing as this app can be used on other OSes too... maybe then just an old fashioned Save icon, that goes grey, would do the job. Even if it is grey all the time, or has a tool tip that says autosaved?

Or to reduce clutter even futher, how about we make the "Save As" button a "Save" button, and add a context menu to it for "Save As"?

phase1geo commented 3 years ago

Well, technically, the user can use the keyboard shortcut "Control-S" whenever they want to force a save to occur.

nekohayo commented 3 years ago

Control-S is not a documented shortcut on my version, and the title does not use the standard " * " asterisk suffix to indicate unsaved state, and as a user I typically also rely on the sensitivity state of the Save button to know whether there are unsaved changes; to not have such a visual indication is worrying/stressful as a user, I really like to know that my data is safe and registered.

Adding the asterisk to the title in the headerbar, and going with the proposed Save button approach in #247 might be a way to solve the issue. I consider "Save as" to be an edge case, I never need to use it after the initial save (and in the rare cases where I do, I go into the hamburger menu where that action is located in the vast majority of GTK apps)

phase1geo commented 3 years ago

I would suggest forking Minder and creating a new project as this save methodology is not in keeping with elementary OS applications. Minder is first and foremost a mind-mapping application designed and written for the elementary app ecosystem.

nekohayo commented 3 years ago

I am not dumb* enough to fork a project for a button.

I am, however, patient and altruistic enough to try to bridge gaps between communities by making constructive suggestions in the hope that you consider them. Realize that me filing bug reports here is me writing love letters to you.

OK you don't want to consider a button as an indication of save state. Fair enough. Technically however, there is still a portion of the suggestions above that could be considered even if not going with the traditionnal save pattern; unless your app spams the disk to save every milisecond and everytime a character gets typed (which is really not something I would recommend, from a performance standpoint), it would cost you nothing to at least display the standard asterisk symbol in the title while there are unsaved changes. Now, do with that suggestion what you will, I rest my case.

*: Forking, with the resulting fragmentation of resources and waste of efforts, is the most foolish act FLOSS zealots can make (right up there with "let's rewrite it from scratch"), unless there's a serious legal/governance issue at stake.

phase1geo commented 3 years ago

Fair enough.

phase1geo commented 3 years ago

Due to some changes that are going into the 2.0 release, I am going to display an indicator in the header bar that will indicate if the map requires saving along with a save button. I believe that these changes already have been applied to the development branch. However, the development branch (which contains code for the 2.0 branch) saves mind maps in a new binary format (as opposed the the 1.x XML format) which will make any maps created with the development branch not backwards compatible, so if you would like to test out the changes, keep this in mind.