On 1 December 2012 16:10, Matthew Brush mbrush@codebrainz.ca wrote:
Hi again,
Attached is a mockup of roughly what I was thinking made in 5 minutes on some website, except I couldn't figure out how to make a warning icon for the infobar and tab label.
Yes thats the sort of thing.
I agree with Lex that a warning icon in the tab (next to filename label or perhaps even replacing the close icon) would be useful to help avoid clobbering files changed on disk when meaning to save files edited "live" with "Save All".
The thing I realised is that with tabs on top and many files open, some are going to be hidden, so an indication only on the tab may not be visible. That was the idea for the "master warning" indication that shows somewhere always visible if any tab has an undismissed infobar. This is unashamedly stolen from the way aircraft systems work :)
Also we could set a flag on the document(s) so that when
you click "Save All", it warns you that you're clobbering file changed on disk that have non-dismissed messages pending or just focus next non-dismissed tab.
This is all getting complicated, but possibly this is an acceptable solution.
Cheers Lex
PS Minor niggle with the concept drawing, if we have 4 buttons then they maybe should be in two columns so the infobar isn't so big vertically.
Cheers, Matthew Brush
On 12-11-30 06:55 PM, Matthew Brush wrote:
On 12-11-30 02:20 PM, Thomas Martitz wrote:
Am 28.11.2012 16:42, schrieb Matthew Brush:
On 12-11-28 05:39 AM, Nick Treleaven wrote:
On 27/11/2012 18:13, Matthew Brush wrote:
On 12-11-27 09:54 AM, Nick Treleaven wrote: > > On 27/11/2012 17:48, Matthew Brush wrote: >> >> We could just drop the Close button altogether since you can already >> close the document by using the close button in the notebook tab, >> the >> close button in the toolbar, the close button in the main menu or by >> using Ctrl+W (or whatever) accelerator. Unlike the "missing on disk" > > > That takes quite a bit longer when you have several files to reload > and > you want to close most of them. This situation actually happens often > for me, I think pretty much as often as I want to reload documents. >
What is your use case for when you want to close a file after it has been externally modified on disk? I understand the case for "externally deleted/moved" just not for "externally changed".
- switching git branches - different branches need different files
open in Geany. After switching I often want to close the unnecessary ones.
- sometimes I have the same file open in two instances of Geany -
sometimes I reuse my 1st instance to open an unrelated file for a quick edit and realize I actually need other files open too, so I start a new instance. On switching back to the 1st Geany detects the change, but I don't want it open any more.
The first item above is the most important. I'm not sure if there are other cases too, but I definitely use Close quite a lot. BTW I'm open to removing it if it actually causes a problem, but a mnemonic clash has other solutions to try first.
So really it sounds like it's not that it's a needed feature, it's a needed feature because another feature - file monitor notification - is annoying already :)
I just couldn't wrap my head around the association between file-on-disk change detection and wanting to close files, but it sounds from your description and Lex's on IRC, that it's almost entirely because of the misfeature of file change detection and when it occurs (tab switching) and that it has already stopped you in your tracks from what you were originally doing and is going to keep doing so as long as the next tab that it switches to after closing is also changed and keeps the blocking dialogs coming.
I wonder why you call it a misfeature. While it's disruptive in some situations, it's generally enormously useful to me.
"misfeature" is the wrong word, "missed feature" works better and sounds similar :)
By "misfeature", I was referring to the fact that the current "file monitoring"[1] is tied to document tab navigation to check if the file has changed, and this in conjunction with the modal dialogs offers this sometimes useful workflow of "ok since you annoyed me anyway, let me quickly deal with something now for all documents so you'll stop annoying me in the near future", where it switches to the next tab because the document to the left was closed and a changed/deleted one might be next to get focus, and continues that cycle of maybe nagging, closing, switching, maybe nagging, closing, switching, maybe nagging later when you switch to another tab in 10 minutes, ...
The reason I was asking in the first place is because I want to eventually get the document-messages branch into master but I want to make sure it doesn't break this workflow (and hopefully improves it). IMO, this dependency between change detection and modal warnings on tab page change could be replaced/enhanced by specific actions accessible in the GUI and with keybindings like "Close All Files Changed on Disk Without Prompting" and "Save All Files not Externally Modified Without Prompting" (of course my names suck). This would allow using "real-time" file monitoring and passively warn the user right away using the document-messages infobar as well as a different tab label color and maybe even a warning icon next to the label in the tab.
Comments and suggestions are welcome, especially how to to lay out the interface for the infobar, the wording of the message, which actions/buttons it should have, and any other useful (inter)actions I might be missing, etc.
Cheers, Matthew Brush
[1] As opposed to the GIO file monitoring code that is currently #ifdef'd out but works pretty good with document-messages branch _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel