INIshell-ng

Issue 857: Working directory dropdown improvements

Reported by Michael Reisecker, Aug 28, 2020

This has caused some confusion for users.

- Is it safe to make the dropdown editable, so that users can enter 
their own working directory?
- It should be documented; I'm just not sure if it better fits the 
user guide or dev guide (since it's in a bit of a limbo state being 
a static element in an otherwise XML-defined area).

Comment 1 by Mathias Bavay, Aug 29, 2020

It could be user-editable, although I hope that the current two 
options would cover the vast majority of cases. On the other hand, 
for most users the whole concept of a working directory is a 
complete mystery... which is tough on us since it is very important 
(otherwise the simulations just don't run: without doing it, none of 
the Snowpack examples could run). Or maybe we should have a 
"?" button next to it to open an information window that 
would explain in details the concept?

Comment 2 by Michael Reisecker, Aug 29, 2020

Some improvements were made with commit f3dd4c7.

Being able to change the path was suggested by Chris who keeps 
multiple installations of snowpack.

The documentation via your suggested help button is rudimentary and 
uses the already available context help (opening the help file and 
flashing the appropriate frame).

(There's also an annoying Qt (?) bug where flashing the frame will 
only work once - no idea why, the calls are identical.)

I'm happy enough with this so I'm closing the issue, but obviously 
this solution is not ideal (mainly because opening the help file 
will close the application).
Status: Fixed

Comment 3 by Michael Reisecker, Sep 1, 2020

Idea: In the future if it's worth it we could have an oldschool 
context help: the user clicks on "Help" in the menu, the 
cursor changes to <-? and we get the object the user clicks on or 
hovers over.

Instead of triggering the mouse click action a tooltip-like (but 
extended) window would appear showing the context help. This help 
could be injected from help.xml - either an already existing node or 
an unrelated one that doesn't show in the user guide (but is in the 
xml, or an included one).
We could give the objects properties with their related help tag to 
connect it with XML nodes.
Essentially, we would replace tooltips with a good help browser with 
links and everything.
Haven't used it in ages but I think Eclipse does this for error 
messages (and e. g. includes a "copy" button).
Sounds complicated but is probably quite doable; the window would 
house a Group object to build the XML node into as usual. Only of 
course, if users are totally confused everywhere and don't want to 
read the existing doc (they don't), which surely also needs an 
overhaul.

Currently by the way there's an annoyance: When the user clicks on 
"help" while not being in the Applications tab, they are 
not notified that the help has in fact been opened.
Not sure I should commit in the middle of a release, so reopening 
the ticket until this has been addressed...
Status: New

Comment 4 by Mathias Bavay, Sep 1, 2020

Yes, I think the current help concept is not very convenient. I 
think that keeping the same idea (that the help is defined in xml 
files) but opening the help in a separate window (that would have 
the same rendering component) could be a possible improvement: then 
the user would not lose his/her simulation and could even keep the 
help open next to the current simulation. Obviously, this will wait 
for after the release!

Created: 1 month 20 days ago by Michael Reisecker

Updated: 1 month 18 days ago

Status: New

Followed by: 1 person

Labels:
Priority:Medium
Type:Enhancement
Component:Docs
Component:UI