Found an ancient STR (1.1-current)

[Albrecht Schlosser]

Hi all,

can you please take a look at this STR?
https://www.fltk.org/str.php?L1086

See my comment (#3) why this STR "appeared" now. I'd like to close it
(or move to 1.4 if still applicable) ASAP to get the roadmap (1.1) clean
again.

TIA.

[Fabien Costantini]

Hi Albrecht,

In my view, it  depends how we interpret the version, it seems that this is an old problem that (according to greg latest feedback on this STR) is still present in 1.4.

I interpret the version as 'the bug appears since versiobn 1.1' which is more helpful than it happens in latest 1.4 branch.

So my vote would be to keep it that way with a version of 1.1 if I interpret correctly that the bug was first detected on 1.1 and still occurs.

We should probably display a message somewhere (maybe a status bar inside of the file content view shomehow confusing) ?

-Fab

--

You received this message because you are subscribed to the Google Groups "fltk.coredev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Fabien Costantini]

Also, about 'clean' consideration, I think that instead of remioving information quality from aSTR; it is probably better to simply state that is no roadmap anymore for some older versions.

Cleaning should not mean that we (inadvertently) silence/hide bugs that still occurs on version even if we don't plan to maintain it anymore.

-Fab

To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.

[Albrecht Schlosser]

On 12.02.2019 18:29 'Fabien Costantini' via fltk.coredev wrote:
> Hi Albrecht,
>
> In my view, it  depends how we interpret the version, it seems that this
> is an old problem that (according to greg latest feedback on this STR)
> is still present in 1.4.

Greg's tests are very much appreciated. So I discovered a very old bug
report of a bug that still exists. Good to know.

> I interpret the version as 'the bug appears since version 1.1' which is

> more helpful than it happens in latest 1.4 branch.

Yep, that's my opinion as well, and that's the reason why I didn't
change the software version and left it at 1.1.

> So my vote would be to keep it that way with a version of 1.1 if I
> interpret correctly that the bug was first detected on 1.1 and still occurs.

Looks so.

> We should probably display a message somewhere (maybe a status bar
> inside of the file content view shomehow confusing) ?

I don't understand what exactly you mean. Please elaborate. If it's a
suggestion how to fix the bug we may discuss it here, but please add it
to the STR as well.

WRT your other message "about 'clean' consideration": I don't intend to
"clean" anything in the sense that I would delete STR's or something
like that. But I'd like to have a clean roadmap for old versions like
1.1, hence we (who ever does this) should try to fix these old bugs first.

Note that I found many more unclassified bug reports and I'm still
working on it. See fltk.bugs from about 17:30 CET to now (19:20 CET),
currently 13 STR's or something like that. I classified bugs correctly
(AFAICT), closed duplicates, and added comments to some more bug reports.

[Fabien Costantini]

>> We should probably display a message somewhere (maybe a status bar 

>> inside of the file content view shomehow confusing) ?

>I don't understand what exactly you mean. Please elaborate. If it's a
>suggestion how to fix the bug we may discuss it here, but please add it
>to the STR as well.

Sorry if my original message is not clear ; I was just suggesting to consider adding a status bar; if we decide to fix this.

This was, instead of using the cumbersome file/folder view content for this purpose.
Will add that remark in the STR.

>WRT your other message "about 'clean' consideration": I don't intend to
"clean" anything in the sense that I would delete STR's or something
like that. But I'd like to have a clean roadmap for old versions like
1.1, hence we (who ever does this) should try to fix these old bugs first.

Great, if cleaning the roadmap does not suppress bugs related to that version (here 1.1)

it makes sense to me too.

[Greg Ercolano]

On 2/12/19 11:19 AM, 'Fabien Costantini' via fltk.coredev wrote:
> Sorry if my original message is not clear ; I was just suggesting to consider adding a status bar; if we decide to fix this.
> This was, instead of using the cumbersome file/folder view content for this purpose.
> Will add that remark in the STR.

If the status bar really caught the user's eye so that they don't
miss it, it'd be OK. And the status bar didn't take up screen space
unless a status message appeared.

But wouldn't it be easier to just splash an error message over
the viewer? e.g. a hidden Fl_Box that appears only when an error
occurs? Would save on screen real estate, and would put the error
where the user's eyes are during browsing.

In the old browser example, I'd probably have made the error message
a dark red instead of just slightly gray, to prevent it from being
mistaken as a filename.

[Fabien Costantini]

>    If the status bar really caught the user's eye so that they don't

>   miss it, it'd be OK. And the status bar didn't take up screen space
>  unless a status message appeared.
>   But wouldn't it be easier to just splash an error message over
>   the viewer? e.g. a hidden Fl_Box that appears only when an error
>   occurs? Would save on screen real estate, and would put the error
>    where the user's eyes are during browsing.

Not sure if we want to have a hidden status bar with nowadays screens but sure it could be done.

A hidden Fl_Box on the top would probably be fine as long as the user doesn't need to acknowledge the message.

I like the idea and especially to be still avoiding to display a dialog/message box with user confirmation in that.case.

[Matthias Melcher]

On MacOS, you can't navigate to directories that are inaccessible anyways. they are grayed out, or don't show in the file browser to begin with. If an invalid path is given by the app, it simply shows the content of the deepest readable directory. For example, /usr/include/foo/bar will simply show the content of /usr/include/ and ignore the rest as if it was a non-existing filename.

I think that this is a feasible solution for FLTK as well. Status bars are an 80's think, and nobody reads them. An error popup is always disrupting. A message across the browser that goes away as soon as the user choose a valid directory is acceptable, but it must not block the "parent directory" functionality, or any other functionality to change, enter, ok, or cancel the dialog.

[Fabien Costantini]

>On MacOS, you can't navigate to directories that are inaccessible anyways. they are grayed out, or don't show in the file browser to >begin with. If an invalid path is given by the app, it simply shows the content of the deepest readable directory. For example, >/usr/include/foo/bar will simply show the content of /usr/include/ and ignore the rest as if it was a non-existing filename.

>I think that this is a feasible solution for FLTK as well. Status bars are an 80's think, and nobody reads them. 

When reading this message now with google Chrome ; 

it displays a contextual status bar overlaid in the bottom left corner whenever we hoover a link or other interactive object,  

and hidden by default as greg suggested...

>An error popup is always disrupting. A message across the browser that goes away as soon as the user choose a valid directory is >acceptable, but it must not block the "parent directory" functionality, or any other functionality to change, enter, ok, or cancel the dialog.

I strongly agree with this.

[Greg Ercolano]

On 2/12/19 2:46 PM, 'Matthias Melcher' via fltk.coredev wrote:
> On MacOS, you can't navigate to directories that are inaccessible anyways. they are grayed out, or don't show in the file browser to begin with. If an invalid path is given by the app, it simply shows the content of the deepest readable directory. For example, /usr/include/foo/bar will simply show the content of /usr/include/ and ignore the rest as if it was a non-existing filename.

I rather like that we show the actual error instead of hiding it.

It prevents sysadmins from having to get involved to tell the user
what the problem is by having to jump in a terminal, drag+drop the
path into an 'ls -la' command to see the real error.

Apple does some UI stuff really well, but they all to often
hide too much from the user.. Like those boot screens that show
an apple logo over the meaningful unix console messages, so when
something goes wrong, you know you could see the error if only
that stupid logo wasn't hiding the errors ;)

Apple has really relegated themselves to "home use only"
when they do stuff like this.

> Status bars are an 80's think, and nobody reads them. An error popup
> is always disrupting. A message across the browser that goes away as
> soon as the user choose a valid directory is acceptable, but it must
> not block the "parent directory" functionality, or any other
> functionality to change, enter, ok, or cancel the dialog.

Yep, good point.. a ".." option mustn't be blocked.