On 5 December 2012 13:04, Matthew Brush mbrush@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'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.
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 :)
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.
Cheers Lex