[Geany-Devel] Document Message/File Monitoring Behaviour (was Re: Bug: Conflicting Keyboard shortcut in "reload file" dialog - ID: 3587465)

Matthew Brush mbrush at codebrainz.ca
Sat Dec 1 02:55:58 UTC 2012

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.

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

More information about the Devel mailing list