severity 1036384 important
retitle 1036384 dillo: Open file dialog pops up in /tmp and forgets opened
file's dir when changing page
thanks
On Sun, 21 May 2023 06:22:17 +0200
Axel Beckert <a...@debian.org> wrote:
> Control: severity -1 minor
> Control: tag -1 upstream
Please, when you modify a submitter's settings make sure beforehand you
have supported your decision with objective reasons, you are right, and
the submitter agrees.
In this case you say nothing about why you consider this is not an
upstream bug, and you didn't support your claim that the severity is
minor on anything besides asserting it, which obviously is no reasoning.
> José Luis González wrote:
> > When I pop up the Open file dialog it always opens in /tmp, forcing you
> > to change to home, which is where it should open.
>
> Where it should open is actually very subjective.
I hope you are not serious.
> And most open
> dialogs don't open in $HOME either but usually where you opened a file
> the last time.
Absolutely agreed. But that can only happen when you have already
opened a file. Otherwise it's impossible, since you wouldn't known
where to chdir() to.
I'm puzzled though, since
1. This is also what I was arguing for. You seemed to understand
something else and argue here that I was wrong and right behaviour is
precisely what I reported as desired right behaviour:
[...] The only exception is when you have already opened a file
and are still displaying it, then it rightly opens in the same
dir, but if you go back to another page and return it forgets.
[...]
This was part of the description of Dillo's current behaviour.
Since the report communicated two related issues and it seems this
one wasn't correctly understood nor it was featured on the subject,
I have updated its title to reflect it.
2. You seem to imply the Open file dialog should open most of the time
where you opened a file last time, which is only right when you are
in a context where that directory still applies, which obviously
requires that the program's current state hasn't moved to something
else.
3. You don't acknowledge that I was reporting that when you return to
the page where you had opened from a file, Dillo shall remember that
file's directory and start the Open File dialog on it, which is not
what it currently does, and which further aligns with what you are
trying to defend.
4. You are supporting your claims on supposed common behaviour, and not
solid reasons.
> Which dillo does btw. to. (Ok, maybe not after it has
> been closed and started again.)
Well, it actually doesn't sometimes when it should, and this was
precisely on my report. See the quote above and the new title.
Furthermore, it makes no sense to start the Open file dialog where you
opened a page that are no longer displaying, as I already explained in
this email. In this case, if the current page doesn't come from a file,
common sense dictates not to start the dialog on a directory that is
not relevant anymore but on the default directory, which in Dillo's
case should be HOME (the other option would have been Desktop, but
it's a plain FLTK program, and knows nothing so far about the
desktop).
> /tmp/ is not the best choice but IMHO a valid one.
If, by your own admission, it's not the best choice, why do you argue
for that on a report that is precisely about the open file dialog
incorrectly popping up by default there?
> At least I manually
> open HTML files in a browser most times in /tmp/ and not in $HOME.
Well, all the better for you, but this is not the usual case, as I
think you admit. :)
$HOME was created for something. This is where user's life usually
begins. Negating this is ignoring how Unix works.
> (And not, the fact that dillo does that is not a patch of mine, just
> coincidence. And probably the reason why I never noticed it.)
1. May we know when I claimed this behaviour came from a patch of yours?
2. You seem to be trying to argue for this being an upstream bug, but
you precisely removed the upstream tag that I had added, which means
exactly the opposite, so I'm mystified.
> Additionally there is the short cut Alt-H to directly jump to your
> home directory.
Moot point as well. The fact that the shortcut exists doesn't mean it's
the right place to begin at. If anything just the opposite: (1) it's
accessing precisely <H>ome, with what this means on English, and (2) if
it exists it's obvious it's a frequent point the user may need to go
to, which further supports my point.
> > Besides, if I click on FLTK's shortcut for /, right up the Filename
> > text entry, it only displays kernel fs dirs: sys, proc, dev, run, and
> > subdirs of these.
>
> Indeed. But it actually shows all mount points (including /home/ for
> me).
I'm frankly having a hard time understanding why
1. dillo's open file dialog should pop up by default on /tmp
2. when I change to / only filesystems mounted from kernel show up, and
not also the regular / directories, and why subdirs of the kernel fs
mounts show up as well if in a directory listing only the contents of
this directory should turn up
3. is it relevant that it shows all mount points when I reported
something else
> Which is maybe not expected, but kinda makes sense.
If it's precisely not expected may we know how it is any right, and
more so makes sense, "kinda" or not?
> It also
> includes / itself and when you click on that you get all files and
> directories in there.
That is completely illogical as well. Why should I have to double click
on / to switch to / when I had already requested so by clicking on the
corresponding button from the opened directory's path? Are you
suggesting that FLTK's path change buttons widget should not work at
all and the user have to request again switching to the same directory
afterwards? You seem to imply as well that using a third party library
should not necessary work in your package.
> > The whole issue is a very serious usability issue.
>
> No, it's not. From my point of view both issues are actually very
> minor.
While your opinion is appreciated as a maintainer it makes no sense to
pretend I'm not right just because you claim it, especially when your
claims are essentially unsupported. I frankly wonder how you can
assert I don't know about interfaces or know less than you if you know
nothing about me.
As for the severity:
important
a bug which has a major effect on the usability of a package,
without rendering it completely unusable to everyone.
minor
a problem which doesn't affect the package's usefulness, and is
presumably trivial to fix.
In this case the bug is presenting the user with /tmp directory every
time (s)he tries to open a file, which is not what the user wants nor
expects, except /very/ special cases, so definitely a usability problem.
It forces the user to switch to HOME almost every time, which puzzles,
wastes time, and becomes tiresome, and Opening a file is a relatively
common operation, so it makes Dillo difficult and inadequate to use on a
regular basis, so definitely the effect on its usability is major,
which means important severity.
Besides, article 4 of the social contract mandates to place our users'
interests first in our priorities, whose interests are what guide us,
and who are our priority besides free software. So if a user explains
that something is a major usability issue to him you simply have to
accept it and place it as a priority, no matter what you think or
prefer. The only exception would be when the user is wrong, which means
you have to argue it rationally if you think (s)he is wrong, and (s)he
must agree in the end, or either you have not explained it correctly
or you were just wrong.
I wonder what your rationale was for asserting severity was minor,
since you only claim "both issues are actually very minor" and "it's
not [a serious usability issue]", both claims unsupported.
And, by the way, you sounded disrespectful, and just trantruming
instead of dealing with the filed bugs. You are, finally, going
against article 4 of the social contract, as already pointed out.
To finish, I will add, besides your discussion, and just to complete the
report, that I experienced this starting dillo both from command line
inside my HOME hierarchy, and from my Desktop's menu, and the bug is
experienced in both cases with very similar behaviour (both show up
in /tmp and differ only on its supposed contents).
