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