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

[Lex Trotman]

[...]
>>>> 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