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".
1. switching git branches - different branches need different files open
in Geany. After switching I often want to close the unnecessary ones.
2. 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
