#1109 Lack of notification on file open failure
Having attempted to open a file from the recently used drop-down list in a situation where the open file operations fails ( the file had been deleted externally ) I just got dumped back where I was.
A bit surprised, I tried again taking care that I was doing what intended do and got the same result.
After several attempts, I finally noticed a very discrete message in the status bar at the bottom of the screen with something like " file not found". So the error was flagged but in such a discrete way that it failed in its primary purpose to alert the user and explain the apparent inaction.
While avoiding a modal dlg and yet another confirmation action before continuing may be a nice design choice, the notification needs to be a lot more visible.
The user's attention is focused on the centre of the screen where he is interacting with the menu system and a slight change in the text in the periphery of vision at the same time as major change happens when the file list disappears, is simply not likely to get noticed.
I would suggest something like a red background for the text and flashing it once or twice to attract the user's attention. It could then revert to its usual grey background as currently implemented.
Related
This is a feature request not a bug.
On 22 July 2015 at 18:36, saucy saucy-forger@users.sf.net wrote:
Related
Bugs: #1109
The feature is present, there is a notification that the file open operation failed. It is defective because it is so discrete that it goes unnoticed. That is really not acceptable with a disk I/O failure.
It is not a coding bug but it is a design bug.
In fact, there is no notification of the I/O operation failure as such but there is record of it in the status bar.
Like I said, not interrupting the work flow with the need to click a button on a model dlg may be a good choice but it does need something that can not be missed. Failure of a file operation MUST be communicated directly and unavoidably.
What it gets called is not that important as long as it gets some attention.
I suspect that calling it a feature request may put it on the bottom of the list, which is why I filed it as a bug.
On 23 July 2015 at 03:16, saucy saucy-forger@users.sf.net wrote:
As you say the feature is present, it works as designed.
Certainly you can propose an improvement to the UI, nobody is gonna
claim its perfect. An issue on github with a concrete proposal for
an improvement to the UI or better still a pull request with code is
the way to go.
Concrete suggestions welcome.
Well, Geany is an open source project, people are not compelled to
work on anything they don't want to, no matter if its a bug or
feature. The project is in the process of moving to github issues,
where all issues are equal in the tracker, but it still requires
"somebody" to propose and code the suggested change.
Related
Bugs: #1109
"Certainly you can propose an improvement to the UI, nobody is gonna
claim its perfect. An issue on github with a concrete proposal for
an improvement to the UI or better still a pull request with code is
the way to go."
I did make a concrete proposal for a solution in the original bug report. I'm affraid I don't have time to get familiar with the code base and code an implementation.
I quite appreciate that no one is obliged to fix it unless they are so inclined. The most I can do is point out the issue and suggest a solution.
Geany is a great tool that has already saved me a lot of time.