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

[Colomban Wendling]

Le 05/12/2012 05:47, Lex Trotman a écrit :
> On 5 December 2012 13:04, Matthew Brush <mbrush at 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