hey! It's about the bug
http://sourceforge.net/tracker/?func=detail&aid=3587465&group_id=153...
i tried to debug it by changing the buttons to YES No buttons, I figured out that the document.c is the file associated with this bug.
original code
static void monitor_reload_file(GeanyDocument *doc) { gchar *base_name = g_path_get_basename(doc->file_name); gint ret;
ret = dialogs_show_prompt(NULL, GTK_STOCK_CLOSE, GTK_RESPONSE_CLOSE, GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL, _("_Reload"), GTK_RESPONSE_ACCEPT, _("Do you want to reload it?"), _("The file '%s' on the disk is more recent than\nthe current buffer."), base_name); g_free(base_name);
if (ret == GTK_RESPONSE_ACCEPT) document_reload_file(doc, doc->encoding); else if (ret == GTK_RESPONSE_CLOSE) document_close(doc); }
Modified code static void monitor_reload_file(GeanyDocument *doc) { gchar *base_name = g_path_get_basename(doc->file_name); gint ret;
ret = dialogs_show_prompt(NULL, GTK_STOCK_CLOSE, GTK_RESPONSE_CLOSE, GTK_STOCK_NO, GTK_RESPONSE_NO, GTK_STOCK_YES, GTK_RESPONSE_YES, _("Do you want to reload it?"), _("The file '%s' on the disk is more recent than\nthe current buffer."), base_name); g_free(base_name);
if (ret == GTK_RESPONSE_YES) document_reload_file(doc, doc->encoding); else if (ret == GTK_RESPONSE_CLOSE) document_close(doc); }
How to test this code locally when I try make install
I get this output
[amit@localhost geany-1.22]$ make install Making install in tagmanager make[1]: Entering directory `/home/amit/Programming/Geany/geany-1.22/tagmanager' Making install in mio make[2]: Entering directory `/home/amit/Programming/Geany/geany-1.22/tagmanager/mio' make[3]: Entering directory `/home/amit/Programming/Geany/geany-1.22/tagmanager/mio' make[3]: Nothing to be done for `install-exec-am'. make[3]: Nothing to be done for `install-data-am'. make[3]: Leaving directory `/home/amit/Programming/Geany/geany-1.22/tagmanager/mio' make[2]: Leaving directory `/home/amit/Programming/Geany/geany-1.22/tagmanager/mio' Making install in include make[2]: Entering directory `/home/amit/Programming/Geany/geany-1.22/tagmanager/include' make[3]: Entering directory `/home/amit/Programming/Geany/geany-1.22/tagmanager/include' make[3]: Nothing to be done for `install-exec-am'. /usr/bin/mkdir -p '/usr/local/include/geany/tagmanager' /usr/bin/mkdir: cannot create directory `/usr/local/include/geany': Permission denied make[3]: *** [install-tagmanager_includeHEADERS] Error 1 make[3]: Leaving directory `/home/amit/Programming/Geany/geany-1.22/tagmanager/include' make[2]: *** [install-am] Error 2 make[2]: Leaving directory `/home/amit/Programming/Geany/geany-1.22/tagmanager/include' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/home/amit/Programming/Geany/geany-1.22/tagmanager' make: *** [install-recursive] Error 1
Can anyone please help me with this so that I can test this, also how to submit the code (ie if I get it right)
ps: attaching the modified document.c.
Thanks
Regards Amit
Sorry, It's running now I forgot to use sudo while running make install. can anyone please check the code.
Thanks
On 27/11/2012 13:27, Amit Sengupta wrote:
hey! It's about the bug
http://sourceforge.net/tracker/?func=detail&aid=3587465&group_id=153...
i tried to debug it by changing the buttons to YES No buttons, I figured out that the document.c is the file associated with this bug.
So in the detect/reload dialog we would have buttons: [_Close] [_No] [_Yes]
instead of: [_Close] [_Cancel] [_Reload]
to fix the _c clashing mnemonic. This seems ok to me, but personally I wonder if:
[_Close] [_No] [_Reload]
is better, as it avoids listing no,yes which is a little odd in order (albeit the Gnome HIG order), and having Reload instead of Yes is clearer IMO.
What does everyone think?
Can anyone please help me with this so that I can test this, also how to submit the code (ie if I get it right)
I don't mind making the change myself as it's easy (once we all agree), so in this case it's not that necessary. But the usual way is to create a patch file in unified diff format. Google 'unified diff patch'.
On 12-11-27 05:50 AM, Nick Treleaven wrote:
On 27/11/2012 13:27, Amit Sengupta wrote:
hey! It's about the bug
http://sourceforge.net/tracker/?func=detail&aid=3587465&group_id=153...
i tried to debug it by changing the buttons to YES No buttons, I figured out that the document.c is the file associated with this bug.
So in the detect/reload dialog we would have buttons: [_Close] [_No] [_Yes]
instead of: [_Close] [_Cancel] [_Reload]
to fix the _c clashing mnemonic. This seems ok to me, but personally I wonder if:
[_Close] [_No] [_Reload]
is better, as it avoids listing no,yes which is a little odd in order (albeit the Gnome HIG order), and having Reload instead of Yes is clearer IMO.
What does everyone think?
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" dialog where I often use the dialog's Close button (to close and re-open new filename), for the "changed on disk" dialog, I find the Close button to not be very useful in practice.
Either way, I also agree with keeping the "Reload" button.
Cheers, Matthew Brush
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.
dialog where I often use the dialog's Close button (to close and re-open new filename), for the "changed on disk" dialog, I find the Close button to not be very useful in practice.
Either way, I also agree with keeping the "Reload" button.
OK, great.
On 27/11/2012 17:54, 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.
And it's not just longer but awkward and repetitive and bug-prone to keep alternating commands quickly.
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".
Cheers, Matthew Brush
On 28 November 2012 05:13, Matthew Brush mbrush@codebrainz.ca 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".
@Matthew, "oh, I still have that generated file open, oops"
@Amit, congratulations you have made your first bugfix for Geany :) As Nick says patches (if you have cloned the git repository, git diff will do it) or for bigger things a pull request on github is the best way to submit.
@Nick, either reload or yes is a valid answer to the question the dialog asks, so I don't care. Agree close should stay.
Cheers Lex
Cheers, Matthew Brush
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 12-11-27 02:20 PM, Lex Trotman wrote:
On 28 November 2012 05:13, Matthew Brush mbrush@codebrainz.ca 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".
@Matthew, "oh, I still have that generated file open, oops"
I was asking for Nick's real-life use case for this, as opposed your hypothetical ones :) Not that it's any of my business, I was just curious where this specifically comes in handy for him, maybe I'm missing something convenient I could be doing.
Cheers, Matthew Brush
On 28 November 2012 13:10, Matthew Brush mbrush@codebrainz.ca wrote:
On 12-11-27 02:20 PM, Lex Trotman wrote:
On 28 November 2012 05:13, Matthew Brush mbrush@codebrainz.ca 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".
@Matthew, "oh, I still have that generated file open, oops"
I was asking for Nick's real-life use case for this, as opposed your hypothetical ones :) Not that it's any of my business, I was just curious where this specifically comes in handy for him, maybe I'm missing something convenient I could be doing.
This is a depressingly common use-case for me, not hypothetical, when I have generated files open (while debugging things like document tool setups) as soon as it works I start closing things, close the one before the generated file and it becomes current, and pops up the annoying reload dialog, and it is very convenient to just close it.
Cheers Lex
Cheers, Matthew Brush
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Am 28.11.2012 03:10, schrieb Matthew Brush:
On 12-11-27 02:20 PM, Lex Trotman wrote:
@Matthew, "oh, I still have that generated file open, oops"
I was asking for Nick's real-life use case for this, as opposed your hypothetical ones :) Not that it's any of my business, I was just curious where this specifically comes in handy for him, maybe I'm missing something convenient I could be doing.
It's not a hypothetical use case, but a very real one. I encounter this every day in my job.
Best regards.
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.
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.
Anyway, thanks for the explanation, I can see how it's useful.
Cheers, Matthew Brush
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.
Best regards.
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
[...]
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
I agree that the infobar is a better way of indicating the file changed and other conditions that the user needs to know, but doesn't need to handle immediately.
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.
As I said on IRC, the current document-messages branch sets the buffer changed status if it detects the file changed. This occurs asynchronously in the background and this means that if I hit save-all I will save the buffer over the changed file with no warning. The current behaviour where the buffer is not marked changed is safer.
As we also discussed, a way of indicating that there are notifications pending on tabs would be very useful, for example a bright orange ! icon added to the tab like gedit does. And maybe a "master caution" for when some of the tabs are off the screen.
Finally as also discussed, the file-changed notification bar needs a close button to maintain the current workflow.
Personally I don't think the global commands are going to be very useful, there is always one file where I want to do something different from the global (guaranteed by Murphy :), and finding that out after you have saved over or closed it is too late. Being forced to step through means you at least give a nano-thought for each one.
Cheers Lex
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
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.
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". 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.
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
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
On 12-11-30 09:10 PM, Matthew Brush 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.
I also made a mockup for "deleted/moved on disk" infobar. I'll put a link to avoid spamming the list:
Mockup for "document changed on disk": http://codebrainz.ca/images/infobar-mockup.png
Mockup for "document deleted (or moved) on disk": http://codebrainz.ca/images/infobar-mockup-deleted.png
Cheers, Matthew Brush
Matthew Brush mbrush@codebrainz.ca schrieb:
On 12-11-30 09:10 PM, Matthew Brush 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.
I also made a mockup for "deleted/moved on disk" infobar. I'll put a link to avoid spamming the list:
Mockup for "document changed on disk": http://codebrainz.ca/images/infobar-mockup.png
Mockup for "document deleted (or moved) on disk": http://codebrainz.ca/images/infobar-mockup-deleted.png
Cheers, Matthew Brush
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Am 01.12.2012 09:44, schrieb Thomas Martitz:
Matthew Brush mbrush@codebrainz.ca schrieb:
On 12-11-30 09:10 PM, Matthew Brush 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. I also made a mockup for "deleted/moved on disk" infobar. I'll put a link to avoid spamming the list: Mockup for "document changed on disk": http://codebrainz.ca/images/infobar-mockup.png Mockup for "document deleted (or moved) on disk": http://codebrainz.ca/images/infobar-mockup-deleted.png Cheers, Matthew Brush
Sorry for the empty mail, my mistake.
I just wanted to say that I like both mockups.
Best regards.
On 01/12/2012 06:16, Matthew Brush wrote:
On 12-11-30 09:10 PM, Matthew Brush 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.
I also made a mockup for "deleted/moved on disk" infobar. I'll put a link to avoid spamming the list:
Thanks for doing the mockups. Infobars probably would be better than the status quo, but I think both of the mockups are too complicated. There are too many options IMO.
I'm not sure if 'Close all externally modified files' is worth having and is a safe workflow, certainly it shouldn't include modified documents.
I don't think we need a Close button. Closing the document can be done in the normal way. Or were you planning on disabling normal closing? That would complicate the UI code.
Mockup for "document changed on disk": http://codebrainz.ca/images/infobar-mockup.png
Mockup for "document deleted (or moved) on disk": http://codebrainz.ca/images/infobar-mockup-deleted.png
I'm not sure that 'Save as' is needed, the user can use 'File->Save As' if needed. (Resave is a good option though).
Le 03/12/2012 14:35, Nick Treleaven a écrit :
On 01/12/2012 06:16, Matthew Brush wrote:
On 12-11-30 09:10 PM, Matthew Brush 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.
I also made a mockup for "deleted/moved on disk" infobar. I'll put a link to avoid spamming the list:
Thanks for doing the mockups. Infobars probably would be better than the status quo, but I think both of the mockups are too complicated. There are too many options IMO.
I'm not sure if 'Close all externally modified files' is worth having and is a safe workflow, certainly it shouldn't include modified documents.
Agreed. I'm not sure it's useful, at least as-is. If we have "close all others", why not "reload all others"? And I'm really not sure it makes sense to suppose that one wants to perform the same action on all files matching the "externally modified" criteria.
I don't think we need a Close button. Closing the document can be done in the normal way. Or were you planning on disabling normal closing? That would complicate the UI code.
IIUC, the idea was that closing the document "the normal way" would ask again if the user didn't make a choice yet. And although it might indeed look duplicate, I think it's important to make it a clearly visible option as an answer to the question. It being a button or something else I don't have an opinion yet.
Mockup for "document changed on disk": http://codebrainz.ca/images/infobar-mockup.png
Mockup for "document deleted (or moved) on disk": http://codebrainz.ca/images/infobar-mockup-deleted.png
I'm not sure that 'Save as' is needed, the user can use 'File->Save As' if needed. (Resave is a good option though).
Agreed. Or simply have only "save" (or similar) that triggers a pre-filled save as dialog, so one could just hit "save" in it to save under the same name. This would (IMO) fill both use-cases of save and save as, and having to agree on the file name on such a case doesn't look like a big issue to me.
Also, as I discussed a bit on IRC (without much success though :D), I'm not completely sure if the "dismiss" button (we agreed this probably wasn't the best name for it BTW) is useful: I personally don't really see why somebody would like to hide the warning while not making a decision on what to do with the file. Though, that's no big deal.
Regards, Colomban
On 03/12/2012 14:18, Colomban Wendling wrote:
Le 03/12/2012 14:35, Nick Treleaven a écrit :
On 01/12/2012 06:16, Matthew Brush wrote:
I also made a mockup for "deleted/moved on disk" infobar. I'll put a link to avoid spamming the list:
Thanks for doing the mockups. Infobars probably would be better than the status quo, but I think both of the mockups are too complicated. There are too many options IMO.
I'm not sure if 'Close all externally modified files' is worth having and is a safe workflow, certainly it shouldn't include modified documents.
Agreed. I'm not sure it's useful, at least as-is. If we have "close all others", why not "reload all others"? And I'm really not sure it makes sense to suppose that one wants to perform the same action on all files matching the "externally modified" criteria.
Exactly, usually I want to reload some and close the others.
I don't think we need a Close button. Closing the document can be done in the normal way. Or were you planning on disabling normal closing? That would complicate the UI code.
IIUC, the idea was that closing the document "the normal way" would ask again if the user didn't make a choice yet. And although it might indeed look duplicate, I think it's important to make it a clearly visible option as an answer to the question. It being a button or something else I don't have an opinion yet.
OK. Presumably 'normal' save or reload would also ask the user for confirmation. Are there any other use cases like these, maybe from plugins?
BTW should we make a release before these changes? Especially if coupled with the file-monitor instead of disk poll change, I think this will need time to stabilize. Perhaps we should delay this to 1.24?
Mockup for "document changed on disk": http://codebrainz.ca/images/infobar-mockup.png
Mockup for "document deleted (or moved) on disk": http://codebrainz.ca/images/infobar-mockup-deleted.png
I'm not sure that 'Save as' is needed, the user can use 'File->Save As' if needed. (Resave is a good option though).
Agreed. Or simply have only "save" (or similar) that triggers a pre-filled save as dialog, so one could just hit "save" in it to save under the same name. This would (IMO) fill both use-cases of save and save as, and having to agree on the file name on such a case doesn't look like a big issue to me.
+1
Also, as I discussed a bit on IRC (without much success though :D), I'm not completely sure if the "dismiss" button (we agreed this probably wasn't the best name for it BTW) is useful: I personally don't really see why somebody would like to hide the warning while not making a decision on what to do with the file. Though, that's no big deal.
Agree, we probably shouldn't allow 'Dismiss'.
[...]
Agreed. I'm not sure it's useful, at least as-is. If we have "close all others", why not "reload all others"? And I'm really not sure it makes sense to suppose that one wants to perform the same action on all files matching the "externally modified" criteria.
Exactly, usually I want to reload some and close the others.
And since it can apply to files for which the tabs are offscreen so you don't know they are affected I could even be persuaded that these global operations could be classified as dangerous, but on the other hand there have been a number or requests for that functionality, but maybe those requests would not apply when the notification is not modal.
I don't think we need a Close button. Closing the document can be done in the normal way. Or were you planning on disabling normal closing? That would complicate the UI code.
IIUC, the idea was that closing the document "the normal way" would ask again if the user didn't make a choice yet. And although it might indeed look duplicate, I think it's important to make it a clearly visible option as an answer to the question. It being a button or something else I don't have an opinion yet.
Lets make them all buttons, links are too easy to overlook.
OK. Presumably 'normal' save or reload would also ask the user for confirmation. Are there any other use cases like these, maybe from plugins?
BTW should we make a release before these changes? Especially if coupled with the file-monitor instead of disk poll change, I think this will need time to stabilize. Perhaps we should delay this to 1.24?
Agree, this branch still has some changes before merge, so there is time for a release, just lets not let the branch rot for another year :)
[...]
Agreed. Or simply have only "save" (or similar) that triggers a pre-filled save as dialog, so one could just hit "save" in it to save under the same name. This would (IMO) fill both use-cases of save and save as, and having to agree on the file name on such a case doesn't look like a big issue to me.
+1
Agree on one save triggering a pre-filled dialog, calling the button save or save-as I'm unsure, it is save-as functionality after all.
Also, as I discussed a bit on IRC (without much success though :D), I'm not completely sure if the "dismiss" button (we agreed this probably wasn't the best name for it BTW) is useful: I personally don't really see why somebody would like to hide the warning while not making a decision on what to do with the file. Though, that's no big deal.
Agree, we probably shouldn't allow 'Dismiss'.
I guess call it "Cancel" as it currently is then.
Cheers Lex
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 12-12-03 01:21 PM, Lex Trotman wrote:
[...]
Also, as I discussed a bit on IRC (without much success though :D), I'm not completely sure if the "dismiss" button (we agreed this probably wasn't the best name for it BTW) is useful: I personally don't really see why somebody would like to hide the warning while not making a decision on what to do with the file. Though, that's no big deal.
Agree, we probably shouldn't allow 'Dismiss'.
I guess call it "Cancel" as it currently is then.
Yeah, "Stop bugging me I know the buffer is out of sync with the file on disk and I wish to keep editing the buffer without this stupid infobar in my way" is just too long to fit on a button :)
Cheers, Matthew Brush
On 27/11/2012 13:50, Nick Treleaven wrote:
So in the detect/reload dialog we would have buttons: [_Close] [_No] [_Yes]
instead of: [_Close] [_Cancel] [_Reload]
to fix the _c clashing mnemonic. This seems ok to me, but personally I wonder if:
[_Close] [_No] [_Reload]
is better, as it avoids listing no,yes which is a little odd in order (albeit the Gnome HIG order), and having Reload instead of Yes is clearer IMO.
Now committed the latter to Git master.
