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

Lex Trotman elextr at gmail.com
Mon Dec 3 23:27:56 UTC 2012


[...]
>>> 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 at lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel


More information about the Devel mailing list