[Geany-Devel] [RFC] Document Messages and File Notification Behaviour (was: buried down deep somewhere)
elextr at gmail.com
Thu Dec 6 21:24:29 UTC 2012
>>>> 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
>>> 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
>> 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 :)
More information about the Devel