There are some cases where the status bar is used to display error messages. Using this method rather than a modal dialogue is UI design choice which certainly has it merits. Dialogues demand a user action and block work flow. This can be annoying if over used.
However, the status bar is on the periphery of vision when attention is usually focused on some user action in the middle of the screen or a menu interaction. Some minor change in black text on a grey background on the periphery of vision may not even be noticed by the user .
One case brought this to my attention recently. I did a file operation and for some reason it failed but the error was shown in the status bar and I did not notice. It appeared that there was no error but it was apparent from the context that nothing had changed so I tried again. It was on the fourth attempt that I notices a very discrete message in the status bar telling me the operation had failed.
I was interacting with the menus on the upper-right section of the screen and the small visual change in status bar was not sufficient to catch the eye.
I can't recall the exact context so it's possible that a modal may have been better in that situation but remaining with the current design, if errors are to be displayed in the status bar, it needs greater visibility.
I would suggest flashing background colour to red once or twice or some similar device to attract the user's attention. This remain non disruptive but ensures that it gets noticed.
This could be wrapped as a status_error() function available to situations where the status bar is being used to display errors that need to be noticed when they happen , rather than status information which is there for reference when the user seeks it .
I think there is some kind of flash method in toolkit but I can't recall a function name.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/781
Geany has also recently started using infobars for non-modal notifications, that is not appropriate for everything, but it isn't used for much at the moment.
Note that major user interface changes should be discussed on the user mailing list, many users are not subscribed to github, and they are more affected by the changes and may have more suggestions than the developers :)
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/781#issuecomment-160265428
I don't see making this move visible in some way a being a "major" UI change but I take your point. I don't really have to get deeply involved in Geany development but I can report bugs.
Can you point me to an example of the infobars you are referring to in Geany?
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/781#issuecomment-160265695
I think that the only thing the info bars are used for at the moment is when a file is open and the underlying file changes/is deleted. Try `touch`ing a file that is open and wait until Geany notices.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/781#issuecomment-160267734
Document messages (infobars) are inappropriate here since they are related to a specific document and in this case there is no document to attach the message to.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/781#issuecomment-160301101
Yes, I think just changing b/g colour once or twice would be sufficient to draw attention to the status bar. I had a quick look and could not see a ready made method, though I'm fairly sure something exists at some level to flash the widget frame.
A colour change should be pretty trivial to code.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/781#issuecomment-160307183
A colour change with a timer should be pretty trivial to code.
Would probably have to add a special style in the `geany.gtkrc` (for gtk2) and `geany.css` (for gtk3) files containing the alternate styles, and then change which style applies to the label widget inside the statusbar from said timer handler. Probably have to put label widget inside an eventbox widget since labels don't have windows to change bg colour of (unless only text color changed). Also have to ensure default colours work with all possible GTK+ theme that users could use. And also to account for people with colour blindness.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/781#issuecomment-160328942
Since we allow themes to screw up our application it would have to be themable. GTK3 themes seem to define `error-colour`, `warning-colour` and so on, but gtk2 doesn't. But it also needs a GUI to turn it off, expecting users to modify themes to control an annoying flashing is not appropriate.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/781#issuecomment-160338603
But it also needs a GUI to turn it off, expecting users to modify themes to control an annoying flashing is not appropriate.
Meh, we already do this with the colour of tab labels and the background colour of search text boxes. Not that I think it's worth it to implement for this use cases, just it wouldn't be setting any precedence.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/781#issuecomment-160347945
Bad precedences should not be followed :)
I also don't think its worth it, "somebody" would need to generate a PR with a concrete proposal if they liked the idea.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/781#issuecomment-160352091
``` expecting users to modify themes to control an annoying flashing is not appropriate. ```
Why would such a feature be "annoying" and require "controlling". ? I find this an odd attitude.
The main issue here is that some error conditions are being displayed in such a discrete manner that the user may totally miss them. Error messages are supposed to be at least "annoying" enough to _ensure_ that they are seen.
Something like changing the b/g colour to some shade of red for 0.5 seconds is not going to spoil anyone's day to the point that they are forced to start editing their gtk themes.
Supporting themes, colour-blindness and other physical of metal handicaps of potential users seems secondary to getting basic functionality of the program to work.
Since the general reaction here seems to much throwing of hands into the air and presenting this a some major development problem I'm closing the issue. I now know that I have to check the status bar every time I do something to make sure it has worked. I guess other Geany users will just have to find out the hard way.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/781#issuecomment-160387172
Closed #781.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/781#event-476999100
Why would such a feature be "annoying" and require "controlling". ? I find this an odd attitude.
See [the infamous HTML <blink> tag](https://en.wikipedia.org/wiki/Blink_element#Usability_and_accessibility) for the reasons.
Supporting themes, colour-blindness and other physical of metal handicaps of potential users seems secondary to getting basic functionality of the program to work.
The basic functionality already works, it logs the message in the status tab for you to review (which could probably stand a hint to look in debug messages for specifics), it logs a message in the debug messages window with specific details about which files, and it posts the temporary statusbar message.
Since the general reaction here seems to much throwing of hands into the air and presenting this a some major development problem I'm closing the issue.
I actually starting working on an alternative way to make it more visible last night, but OK, more time to work on other stuff this weekend :)
I now know that I have to check the status bar every time I do something to make sure it has worked. I guess other Geany users will just have to find out the hard way.
Geany makes a big stink for actual errors, including modal dialogs and document-modal infobar messages. It's only rather quiet about advisory messages that aren't hard errors, though it still posts them in the 3 ways mentioned above.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/781#issuecomment-160431664
github-comments@lists.geany.org