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

[Lex Trotman]

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'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