[Geany-Devel] [RFC] Document Messages and File Notification Behaviour (was: buried down deep somewhere)

Matthew Brush mbrush at codebrainz.ca
Mon Dec 3 21:48:24 UTC 2012

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 

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 

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?

Matthew Brush

More information about the Devel mailing list