Hi All,
I'm making this a new thread since I wanted it not to be buried down so deep and I don't know how to do it properly, sorry if the quotations and stuff get messed up :)
I've added some discussion topics inline down below. Apologies in advance that it's a bit long winded but I wanted to make sure to explain it properly so we are all on the same page.
On 12-12-03 09:05 AM, Nick Treleaven wrote:> 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.
The only reason I put that there was to allow the workflow discussed in this thread that you, Lex and Thomas mentioned about closing a bunch of generated files when one of them is detected to change on disk. I personally wouldn't use it and I wouldn't have added to the mockup except as the result of the discussions here :)
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?
I've done some experimenting on ways to do this. I propose documents get a new "flag" called "doc->priv->notifications_pending" (or whatever). When a document message is posted, the flag is set to TRUE, the infobar is shown within the tab page and tab's close icon changes to the stock-id of the last (or most "important", see below) message. While the tab's icon is not close (when notifications are pending) and the button is clicked, it simply focuses the document (document_show_tab() or whatever), or puts up a modal dialog saying "The tab you are closing has notifications pending, are you sure you want to close it without reviewing them?" before it lets you close it (also for save/save all?). One question is what should clear the "notifications_pending" flag, be it simply having shown the user the tab, confirming a modal dialog, or using the equivalent of a "Dismiss" button in the info bar. For easier inline discussion, I'll itemize the concepts I just discussed:
* Notion that documents have "notifications" and they can be "pending" (not yet seen/acknowledged)
* Whether we want to use the tab "close" button icon to indicate the type of the last notification that is pending. Alternatives are (existing orange) different color tab label or an additional icon in the tab to the left of the label.
* What happens when you click the "close" button in the tab (or file menu, etc), and there are notifications pending? Does it just focus the document/tab or show a special modal warning dialog or something else?
* What clears the "notifications pending" status of a document? Should it be the modal dialog from last item, or a "Dismiss" (name TBD) button in the infobar itself or something else?
* What actions are "dangerous" to perform while notifications are pending? It seems like these might only be ones that don't work on the "current document" since it's visible and the user will be looking at the notification at the time of the action.
- File Menu and Toolbar: - Close All - Save All - Tab Context/RightClick Menu - Close/Close All - Tab "Close" button
One problem I noticed with my document-messages branch is that it treats all notifications the same, be it important disk-change events or from other parts of the code (or eventually plugins maybe). From trial and error, I believe the best approach for this is to have a special top-most notification place where important messages can go, and when one of those is posted, it's stock-id overrides any of the normal notification's stock-id in the tab "close" button. Here's an ASCII digram of the widget layout inside the notebook page:
|------------|___________________________________ | main.c [!] | documents.c [i] | notebook.c [x] | |--------------------------------------------------------| - | Warning! [Blah] | VBOX2 | | It hit the fan! [Blah] | | |========================================================| | | Info: [Ok] | | | I'm not so important :( | | VBOX1 ---------------------------------------------------------| VBOX3 | | Info: [Ok] | | | I'm not even important enough for you to see | | | me because I'd take up too much screen space. | | |--------------------------------------------------------| - | #include <stdio.h> |^| | int main() { | | | return 0; | | | } | | | | | | |v| |--------------------------------------------------------|
Where VBOXes would be separate places to pack the infobars, be it one real GtkVBox and caring about positions or 2 separate, one for each "message area" in a parent vbox (like in the ASCII mockup) or however. IMO, the "important" messages (disk-change, failures, etc) should only be allowed to be 1 message tall, replacing the last if one is already shown (usually ok for disk-change events since latest change is only important IIUC). The number of "normal" notifications allowed at a time is already configurable in the document-messages branch IIRC. Having only "important" also avoids having to deal with overflows and complicated priorities and such if it was all in one "queue".
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?
I don't have much opinion about whether to release soon, or before these changes, but I don't think we should merge them into master and then do a release right away :) The stuff in document-messages *definitively* not in a releasable state right now, but it's not much more work to make it usable for getting into master for more rigorous development/review/testing.
IMO, before we merge this we should bump GTK+ min version to 2.18 to avoid a few #ifdefs and backwards compat stuff it has now.
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'.
Thomas also mentioned on IRC that Gedit makes a document "read-only" when it detects disk-changes, which seems like a completely sane and safe thing to do, although potentially also annoying. Do we want to do this as well, in addition to the stuff being discussed above?
Cheers, Matthew Brush
[...]
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.
The only reason I put that there was to allow the workflow discussed in this thread that you, Lex and Thomas mentioned about closing a bunch of generated files when one of them is detected to change on disk. I personally wouldn't use it and I wouldn't have added to the mockup except as the result of the discussions here :)
As I said on the other thread, such global operations are risky, but have been requested multiple times, though the reason for those requests might be removed by the use of infobar.
And using a link to do significant global actions without confirmation is really bad IMO, we are generally trained that clicking links will go to another page, not perform an action.
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?
I've done some experimenting on ways to do this. I propose documents get a new "flag" called "doc->priv->notifications_pending" (or whatever). When a document message is posted, the flag is set to TRUE, the infobar is shown within the tab page and tab's close icon changes to the stock-id of the last (or most "important", see below) message. While the tab's icon is not close (when notifications are pending) and the button is clicked, it simply focuses the document (document_show_tab() or whatever), or puts up a modal dialog saying "The tab you are closing has notifications pending, are you sure you want to close it without reviewing them?" before it lets you close it (also for save/save all?). One question is what should clear the "notifications_pending" flag, be it simply having shown the user the tab, confirming a modal dialog, or using the equivalent of a "Dismiss" button in the info bar. For easier inline discussion, I'll itemize the concepts I just discussed:
- Notion that documents have "notifications" and they can be "pending" (not
yet seen/acknowledged)
The question of course is when do they become "seen" and not "pending" ?
- Whether we want to use the tab "close" button icon to indicate the type of
the last notification that is pending. Alternatives are (existing orange) different color tab label or an additional icon in the tab to the left of the label.
Prefer separate icon, the close button still closes so it should continue to have that icon. Just a colour change is bad accessability. Separate icon does not need to depend on colour and can then also be used to indicate "changed" status instead of just changing tab text colour as we do now.
As you noted on IRC, you forgot my suggestion of a common indication for when tabs are offscreen.
- What happens when you click the "close" button in the tab (or file menu,
etc), and there are notifications pending? Does it just focus the document/tab or show a special modal warning dialog or something else?
The point of infobars is to reduce modal interruptions to workflow, lets not re-introduce them :(
- What clears the "notifications pending" status of a document? Should it be
the modal dialog from last item, or a "Dismiss" (name TBD) button in the infobar itself or something else?
Definitely the "Cancel" (aka "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" :) button on the infobar.
Not sure there is anything else.
- What actions are "dangerous" to perform while notifications are pending?
It seems like these might only be ones that don't work on the "current document" since it's visible and the user will be looking at the notification at the time of the action.
- File Menu and Toolbar:
- Close All
- Save All
- Tab Context/RightClick Menu
- Close/Close All
- Tab "Close" button
To answer this we need to know what the conditions and messages are, a list of all conditions and dialogs would be good so we can design the overall error handling system use of modal dialogs and infobars for the right mix of safey and efficient workflow. At the moment we are working on guesswork.
One problem I noticed with my document-messages branch is that it treats all notifications the same, be it important disk-change events or from other parts of the code (or eventually plugins maybe). From trial and error, I believe the best approach for this is to have a special top-most notification place where important messages can go, and when one of those is posted, it's stock-id overrides any of the normal notification's stock-id in the tab "close" button. Here's an ASCII digram of the widget layout inside the notebook page:
|------------|___________________________________ | main.c [!] | documents.c [i] | notebook.c [x] | |--------------------------------------------------------| - | Warning! [Blah] | VBOX2 | | It hit the fan! [Blah] | | |========================================================| | | Info: [Ok] | | | I'm not so important :( | | VBOX1 ---------------------------------------------------------| VBOX3 | | Info: [Ok] | | | I'm not even important enough for you to see | | | me because I'd take up too much screen space. | | |--------------------------------------------------------| - | #include <stdio.h> |^| | int main() { | | | return 0; | | | } | | | | | | |v| |--------------------------------------------------------|
Where VBOXes would be separate places to pack the infobars, be it one real GtkVBox and caring about positions or 2 separate, one for each "message area" in a parent vbox (like in the ASCII mockup) or however. IMO, the "important" messages (disk-change, failures, etc) should only be allowed to be 1 message tall, replacing the last if one is already shown (usually ok for disk-change events since latest change is only important IIUC). The number of "normal" notifications allowed at a time is already configurable in the document-messages branch IIRC. Having only "important" also avoids having to deal with overflows and complicated priorities and such if it was all in one "queue".
I think this is backasswards, important messages are, well *important* so they should show all of them (though no more than one of each type, eg one file changed/delete/renamed) and the unimportant ones should be limited to serial, maybe with a count, eg 1 of n shown somewhere.
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?
I don't have much opinion about whether to release soon, or before these changes, but I don't think we should merge them into master and then do a release right away :) The stuff in document-messages *definitively* not in a releasable state right now, but it's not much more work to make it usable for getting into master for more rigorous development/review/testing.
I think there is *some* more work needed to make it match these discussions, so its not mergeable immediately.
Those with experience (eg Frank for translations) is it ok to release now in runup to end of year or better to wait for next year?
IMO, before we merge this we should bump GTK+ min version to 2.18 to avoid a few #ifdefs and backwards compat stuff it has now.
Which would say we *must* release first.
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'.
Thomas also mentioned on IRC that Gedit makes a document "read-only" when it detects disk-changes, which seems like a completely sane and safe thing to do, although potentially also annoying. Do we want to do this as well, in addition to the stuff being discussed above?
No it blocks editing just like a modal dialog, this is another example of the dumb it down Gnome approach :(
Cheers Lex
Cheers, Matthew Brush _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 03/12/2012 21:48, Matthew Brush wrote:
On 12-12-03 09:05 AM, Nick Treleaven wrote: On 03/12/2012 14:18, Colomban Wendling wrote:
Le 03/12/2012 14:35, Nick Treleaven a écrit :
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?
I've done some experimenting on ways to do this. I propose documents get a new "flag" called "doc->priv->notifications_pending" (or whatever). When a document message is posted, the flag is set to TRUE, the infobar is shown within the tab page and tab's close icon changes to the stock-id of the last (or most "important", see below) message. While the tab's icon is not close (when notifications are pending) and the button is clicked, it simply focuses the document (document_show_tab() or whatever), or puts up a modal dialog saying "The tab you are closing has notifications pending, are you sure you want to close it without reviewing them?" before it lets you close it (also for save/save all?). One question is what should clear the "notifications_pending" flag, be it simply having shown the user the tab, confirming a modal dialog, or using the equivalent of a "Dismiss" button in the info bar. For easier inline discussion, I'll itemize the concepts I just discussed:
- Notion that documents have "notifications" and they can be "pending"
(not yet seen/acknowledged)
- Whether we want to use the tab "close" button icon to indicate the
type of the last notification that is pending. Alternatives are (existing orange) different color tab label or an additional icon in the tab to the left of the label.
- What happens when you click the "close" button in the tab (or file
menu, etc), and there are notifications pending? Does it just focus the document/tab or show a special modal warning dialog or something else?
- What clears the "notifications pending" status of a document? Should
it be the modal dialog from last item, or a "Dismiss" (name TBD) button in the infobar itself or something else?
- What actions are "dangerous" to perform while notifications are
pending? It seems like these might only be ones that don't work on the "current document" since it's visible and the user will be looking at the notification at the time of the action.
- File Menu and Toolbar:
- Close All
- Save All
- Tab Context/RightClick Menu
- Close/Close All
- Tab "Close" button
One problem I noticed with my document-messages branch is that it treats all notifications the same, be it important disk-change events or from other parts of the code (or eventually plugins maybe). From trial and error, I believe the best approach for this is to have a special top-most notification place where important messages can go, and when one of those is posted, it's stock-id overrides any of the normal notification's stock-id in the tab "close" button. Here's an ASCII digram of the widget layout inside the notebook page:
I'm now having serious doubts about whether this complexity is worth it. I really have no issues personally with the current modal dialogs. Modal dialogs are a good fit for important information that needs immediate consideration, like potential data loss.
This extra complexity doesn't seem to provide much benefit over the status quo IMO.
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'.
BTW what I meant here was not allowing removal of the message, whatever it's called, so forcing a response.
Thomas also mentioned on IRC that Gedit makes a document "read-only" when it detects disk-changes, which seems like a completely sane and safe thing to do, although potentially also annoying. Do we want to do this as well, in addition to the stuff being discussed above?
Might be good, except when the document has modifications already.
On 12-12-04 06:00 AM, Nick Treleaven wrote:
On 03/12/2012 21:48, Matthew Brush wrote:
On 12-12-03 09:05 AM, Nick Treleaven wrote: On 03/12/2012 14:18, Colomban Wendling wrote:
Le 03/12/2012 14:35, Nick Treleaven a écrit :
[...] One problem I noticed with my document-messages branch is that it treats all notifications the same, be it important disk-change events or from other parts of the code (or eventually plugins maybe). From trial and error, I believe the best approach for this is to have a special top-most notification place where important messages can go, and when one of those is posted, it's stock-id overrides any of the normal notification's stock-id in the tab "close" button. Here's an ASCII digram of the widget layout inside the notebook page:
I'm now having serious doubts about whether this complexity is worth it. I really have no issues personally with the current modal dialogs. Modal dialogs are a good fit for important information that needs immediate consideration, like potential data loss.
This extra complexity doesn't seem to provide much benefit over the status quo IMO.
IMO, it has a huge benefit. My #1 pet peeve with Geany is the modal dialogs on file-change. However we do it, I *really* think we need to get rid modal dialogs for file notifications on tab change and it also seems like an ideal opportunity to start using the existing file monitoring code.
I'm open to less complex solutions to this end, although I don't actually agree that the proposed ideas are "too" complex for the ground they actually cover.
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'.
BTW what I meant here was not allowing removal of the message, whatever it's called, so forcing a response.
It's almost exactly like the "Cancel" button on the current modal dialogs, with the exception that using the infobar you can still operate on the buffer in the remaining screen-estate below the infobar without having pressed it. It just means "OK, thanks for letting me know, go away now".
Thomas also mentioned on IRC that Gedit makes a document "read-only" when it detects disk-changes, which seems like a completely sane and safe thing to do, although potentially also annoying. Do we want to do this as well, in addition to the stuff being discussed above?
Might be good, except when the document has modifications already.
IIUC, the idea is to prevent any further modifications to the buffer until the user has acknowledged that they know what's going on.
Cheers, Matthew Brush
On 5 December 2012 13:04, Matthew Brush mbrush@codebrainz.ca wrote:
On 12-12-04 06:00 AM, Nick Treleaven wrote:
On 03/12/2012 21:48, Matthew Brush wrote:
On 12-12-03 09:05 AM, Nick Treleaven wrote: On 03/12/2012 14:18, Colomban Wendling wrote:
Le 03/12/2012 14:35, Nick Treleaven a écrit :
[...] One problem I noticed with my document-messages branch is that it treats all notifications the same, be it important disk-change events or from other parts of the code (or eventually plugins maybe). From trial and error, I believe the best approach for this is to have a special top-most notification place where important messages can go, and when one of those is posted, it's stock-id overrides any of the normal notification's stock-id in the tab "close" button. Here's an ASCII digram of the widget layout inside the notebook page:
I'm now having serious doubts about whether this complexity is worth it. I really have no issues personally with the current modal dialogs. Modal dialogs are a good fit for important information that needs immediate consideration, like potential data loss.
This extra complexity doesn't seem to provide much benefit over the status quo IMO.
IMO, it has a huge benefit. My #1 pet peeve with Geany is the modal dialogs on file-change. However we do it, I *really* think we need to get rid modal dialogs for file notifications on tab change and it also seems like an ideal opportunity to start using the existing file monitoring code.
Agree that this is a PITA. Since there is a solution available, why not improve the user experience?
I'm open to less complex solutions to this end, although I don't actually agree that the proposed ideas are "too" complex for the ground they actually cover.
Instead of trying to solve the whole thing now (which is where the complexity is), maybe we should just do the file-changed notification initially in a simple way. We can easliy migrate other notifications over time where they are suitable for non-modal/non-interrupt notification of the user, and then consider things like priorities etc if we actually find that multiple notifications are occurring. And notifications that are not appropriate can be left modal.
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'.
BTW what I meant here was not allowing removal of the message, whatever it's called, so forcing a response.
The whole point of using infobar is to not force the user to respond :)
It's almost exactly like the "Cancel" button on the current modal dialogs, with the exception that using the infobar you can still operate on the buffer in the remaining screen-estate below the infobar without having pressed it. It just means "OK, thanks for letting me know, go away now".
Thomas also mentioned on IRC that Gedit makes a document "read-only" when it detects disk-changes, which seems like a completely sane and safe thing to do, although potentially also annoying. Do we want to do this as well, in addition to the stuff being discussed above?
Might be good, except when the document has modifications already.
And it also forces the user to respond immediately, whichis what we want to avoid.
Cheers Lex
Am 05.12.2012 05:47, schrieb Lex Trotman:
On 5 December 2012 13:04, Matthew Brush mbrush@codebrainz.ca wrote:
On 12-12-04 06:00 AM, Nick Treleaven wrote:
On 03/12/2012 21:48, Matthew Brush wrote:
On 12-12-03 09:05 AM, Nick Treleaven wrote: On 03/12/2012 14:18, Colomban Wendling wrote:
Le 03/12/2012 14:35, Nick Treleaven a écrit :
[...] One problem I noticed with my document-messages branch is that it treats all notifications the same, be it important disk-change events or from other parts of the code (or eventually plugins maybe). From trial and error, I believe the best approach for this is to have a special top-most notification place where important messages can go, and when one of those is posted, it's stock-id overrides any of the normal notification's stock-id in the tab "close" button. Here's an ASCII digram of the widget layout inside the notebook page:
I'm now having serious doubts about whether this complexity is worth it. I really have no issues personally with the current modal dialogs. Modal dialogs are a good fit for important information that needs immediate consideration, like potential data loss.
This extra complexity doesn't seem to provide much benefit over the status quo IMO.
IMO, it has a huge benefit. My #1 pet peeve with Geany is the modal dialogs on file-change. However we do it, I *really* think we need to get rid modal dialogs for file notifications on tab change and it also seems like an ideal opportunity to start using the existing file monitoring code.
Agree that this is a PITA. Since there is a solution available, why not improve the user experience?
I agree, the modal dialog is horrible, especially when you get them multiple times in a row (since it pops up for each changed document) which is not uncommon after switching branches/tags in a VCS.
Thomas also mentioned on IRC that Gedit makes a document "read-only" when it detects disk-changes, which seems like a completely sane and safe thing to do, although potentially also annoying. Do we want to do this as well, in addition to the stuff being discussed above?
Might be good, except when the document has modifications already.
And it also forces the user to respond immediately, whichis what we want to avoid.
Wrong. You can still give no immediately response, e.g. by changing to another document or just viewing the document. Requiring an action if you are actually going to deal with the document in question is OK for me.
FWIW, aligning with Gedit might be more convinient for newcomers that come from gedit. This doesn't have to be a reason for us to do anything, but might become an interesting point if Mint really replaces Gedit with Geany.
Best regards.
[...]
Agree that this is a PITA. Since there is a solution available, why not improve the user experience?
I agree, the modal dialog is horrible, especially when you get them multiple times in a row (since it pops up for each changed document) which is not uncommon after switching branches/tags in a VCS.
or when looking at generated files whilst debugging the program that generates them.
Thomas also mentioned on IRC that Gedit makes a document "read-only" when it detects disk-changes, which seems like a completely sane and safe thing to do, although potentially also annoying. Do we want to do this as well, in addition to the stuff being discussed above?
Might be good, except when the document has modifications already.
And it also forces the user to respond immediately, whichis what we want to avoid.
Wrong. You can still give no immediately response, e.g. by changing to another document or just viewing the document. Requiring an action if you are actually going to deal with the document in question is OK for me.
Well, I don't really agree with being forced to do something to continue use of a file, *I'M* in charge of this program, not the other way around </rant> but its not that big a point.
FWIW, aligning with Gedit might be more convinient for newcomers that come from gedit. This doesn't have to be a reason for us to do anything, but might become an interesting point if Mint really replaces Gedit with Geany.
But this is a big point, as a matter of principle, Geany should not compromise being the best (lightweight) IDE it can be just to be similar to some dumbed down version.
Cheers Lex
Best regards.
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 06/12/2012 09:08, Lex Trotman wrote:
[...]
Agree that this is a PITA. Since there is a solution available, why not improve the user experience?
I agree, the modal dialog is horrible, especially when you get them multiple times in a row (since it pops up for each changed document) which is not uncommon after switching branches/tags in a VCS.
or when looking at generated files whilst debugging the program that generates them.
Just to explain my workflow a little: I don't switch 'through' tabs to get to the one I want, I choose the one I want directly or by Ctrl-tab. So I do get hit by unwanted reload decisions, but only when closing documents.
For my workflow, it is never multiple times in a row, unless I choose not to reload a file and close it instead. I can avoid the multiple prompts when I want to just by choosing reload once. I think this is a significant point, but I accept that people that page through their documents would suffer the multiple reload prompt scenario, and that that is annoying.
Thomas also mentioned on IRC that Gedit makes a document "read-only" when it detects disk-changes, which seems like a completely sane and safe thing to do, although potentially also annoying. Do we want to do this as well, in addition to the stuff being discussed above?
Might be good, except when the document has modifications already.
And it also forces the user to respond immediately, whichis what we want to avoid.
Wrong. You can still give no immediately response, e.g. by changing to another document or just viewing the document. Requiring an action if you are actually going to deal with the document in question is OK for me.
Well, I don't really agree with being forced to do something to continue use of a file, *I'M* in charge of this program, not the other way around </rant> but its not that big a point.
It comes down to whether the user would want the editor to protect them from editing a document that they actually want to reload first. Note that in this scenario edits can happen from 'Replace All in Session', i.e. without even switching to the document that is changed on disk.
FWIW, aligning with Gedit might be more convinient for newcomers that come from gedit. This doesn't have to be a reason for us to do anything, but might become an interesting point if Mint really replaces Gedit with Geany.
But this is a big point, as a matter of principle, Geany should not compromise being the best (lightweight) IDE it can be just to be similar to some dumbed down version.
Agree, we should optimize for programmers.
[...]
Wrong. You can still give no immediately response, e.g. by changing to another document or just viewing the document. Requiring an action if you are actually going to deal with the document in question is OK for me.
Well, I don't really agree with being forced to do something to continue use of a file, *I'M* in charge of this program, not the other way around </rant> but its not that big a point.
It comes down to whether the user would want the editor to protect them from editing a document that they actually want to reload first. Note that in this scenario edits can happen from 'Replace All in Session', i.e. without even switching to the document that is changed on disk.
Yes, thats a problem scenario, at least if you also do a save-all without checking. I guess setting the file read-only is a simple way of doing that.
But should we then indicate that some replacements were *not* made due to the read_only buffers. ATM the replace_in_session() calls document_replace_all() which calls document_replace_range() which finally checks for read_only and simply returns 0 changes made. Probably replace_in_session should do the readonly check and report how many buffers were skipped for that reason.
Also if you do switch to the tab of the file changed on disk it will have both buffer changed (red text) and file changed infobar conditions, probably more confusing than helpful since I suspect many people have the same idea as Matthew, that red text indicates *any* condition that causes the buffer to not match the file, whereas it really means that the *user* has changed the buffer. This situation will be avoided if the buffer is read_only.
Cheers Lex
Le 05/12/2012 05:47, Lex Trotman a écrit :
On 5 December 2012 13:04, Matthew Brush mbrush@codebrainz.ca wrote:
On 12-12-04 06:00 AM, Nick Treleaven wrote:
On 03/12/2012 21:48, Matthew Brush wrote:
On 12-12-03 09:05 AM, Nick Treleaven wrote: On 03/12/2012 14:18, Colomban Wendling wrote:
Le 03/12/2012 14:35, Nick Treleaven a écrit :
[...] One problem I noticed with my document-messages branch is that it treats all notifications the same, be it important disk-change events or from other parts of the code (or eventually plugins maybe). From trial and error, I believe the best approach for this is to have a special top-most notification place where important messages can go, and when one of those is posted, it's stock-id overrides any of the normal notification's stock-id in the tab "close" button. Here's an ASCII digram of the widget layout inside the notebook page:
I'm now having serious doubts about whether this complexity is worth it. I really have no issues personally with the current modal dialogs. Modal dialogs are a good fit for important information that needs immediate consideration, like potential data loss.
This extra complexity doesn't seem to provide much benefit over the status quo IMO.
IMO, it has a huge benefit. My #1 pet peeve with Geany is the modal dialogs on file-change. However we do it, I *really* think we need to get rid modal dialogs for file notifications on tab change and it also seems like an ideal opportunity to start using the existing file monitoring code.
Agree that this is a PITA. Since there is a solution available, why not improve the user experience?
I agree, when this dialogs pops up when I just want to "pass over" a tab it's annoying, whereas a "modal infobar" (modal to the document and not to whole Geany) would be fine with very few behavioral changes -- I'm not saying it's what needs to be done, just that having a modal "dialog" that only blocks the document would be just fine from my POV: I wouldn't mind answering it if I want to deal with the document, and I wouldn't have to answer it if I don't.
I'm open to less complex solutions to this end, although I don't actually agree that the proposed ideas are "too" complex for the ground they actually cover.
Instead of trying to solve the whole thing now (which is where the complexity is), maybe we should just do the file-changed notification initially in a simple way. We can easliy migrate other notifications over time where they are suitable for non-modal/non-interrupt notification of the user, and then consider things like priorities etc if we actually find that multiple notifications are occurring. And notifications that are not appropriate can be left modal.
Agreed, and I agree that from my thread-reader POV the thing you (Matthew) propose looks complex. Maybe it's not that true actually, but the multiple-notifications, multiple-levels stuff doesn't look simple.
BTW, I'm wondering in which cases multiple notifications would be really useful? If a file changed on disc, you won't need a "write failed" info, neither the other way around -- they are somewhat exclusive. So OK, maybe it'd be "cool" to support more, but currently I don't see what would be the use case?
I'm not saying it's not great (I didn't test the branch), just wonder if it's not a little too powerful for what we actually need?
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'.
BTW what I meant here was not allowing removal of the message, whatever it's called, so forcing a response.
The whole point of using infobar is to not force the user to respond :)
No, the whole point of the infobar is not to force the user to respond *if she doesn't wanna deal with that document* ;)
It's almost exactly like the "Cancel" button on the current modal dialogs, with the exception that using the infobar you can still operate on the buffer in the remaining screen-estate below the infobar without having pressed it. It just means "OK, thanks for letting me know, go away now".
Thomas also mentioned on IRC that Gedit makes a document "read-only" when it detects disk-changes, which seems like a completely sane and safe thing to do, although potentially also annoying. Do we want to do this as well, in addition to the stuff being discussed above?
Might be good, except when the document has modifications already.
And it also forces the user to respond immediately, whichis what we want to avoid.
Again, only if she wants to touch that very document (and as said, I would be fine with that).
Regards, Colomban
[...]
I'm now having serious doubts about whether this complexity is worth it. I really have no issues personally with the current modal dialogs. Modal dialogs are a good fit for important information that needs immediate consideration, like potential data loss.
This extra complexity doesn't seem to provide much benefit over the status quo IMO.
IMO, it has a huge benefit. My #1 pet peeve with Geany is the modal dialogs on file-change. However we do it, I *really* think we need to get rid modal dialogs for file notifications on tab change and it also seems like an ideal opportunity to start using the existing file monitoring code.
Agree that this is a PITA. Since there is a solution available, why not improve the user experience?
I agree, when this dialogs pops up when I just want to "pass over" a tab it's annoying, whereas a "modal infobar" (modal to the document and not to whole Geany) would be fine with very few behavioral changes -- I'm not saying it's what needs to be done, just that having a modal "dialog" that only blocks the document would be just fine from my POV: I wouldn't mind answering it if I want to deal with the document, and I wouldn't have to answer it if I don't.
Agree the absolute must is to be non-modal for the application, prefer not being modal for the document either, but as I said it isn't a big point.
I'm open to less complex solutions to this end, although I don't actually agree that the proposed ideas are "too" complex for the ground they actually cover.
Instead of trying to solve the whole thing now (which is where the complexity is), maybe we should just do the file-changed notification initially in a simple way. We can easliy migrate other notifications over time where they are suitable for non-modal/non-interrupt notification of the user, and then consider things like priorities etc if we actually find that multiple notifications are occurring. And notifications that are not appropriate can be left modal.
Agreed, and I agree that from my thread-reader POV the thing you (Matthew) propose looks complex. Maybe it's not that true actually, but the multiple-notifications, multiple-levels stuff doesn't look simple.
BTW, I'm wondering in which cases multiple notifications would be really useful? If a file changed on disc, you won't need a "write failed" info, neither the other way around -- they are somewhat exclusive. So
Yes, thats why I suggested just try it, analysing what multiple messages might occur is too hard.
OK, maybe it'd be "cool" to support more, but currently I don't see what would be the use case?
I'm not saying it's not great (I didn't test the branch), just wonder if it's not a little too powerful for what we actually need?
> 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'.
BTW what I meant here was not allowing removal of the message, whatever it's called, so forcing a response.
The whole point of using infobar is to not force the user to respond :)
No, the whole point of the infobar is not to force the user to respond *if she doesn't wanna deal with that document* ;)
Agree to disagree :)
Cheers Lex