Skip to content

Commit

Permalink
gui,browser: save state in home folder
Browse files Browse the repository at this point in the history
sbourdeauducq committed Apr 15, 2016
1 parent e1a2290 commit d4ba525
Showing 3 changed files with 18 additions and 4 deletions.
2 changes: 2 additions & 0 deletions RELEASE_NOTES.rst
Original file line number Diff line number Diff line change
@@ -34,6 +34,8 @@ unreleased [2.x]
Experiments no longer need to do it explicitly.
* The result folders are formatted "%Y-%m-%d/%H instead of "%Y-%m-%d/%H-%M".
(i.e. grouping by day and then by hour, instead of by day and then by minute)
* GUI tools save their state file in the user's home directory instead of the
current directory.


unreleased [1.0rc3]
10 changes: 8 additions & 2 deletions artiq/frontend/artiq_browser.py
Original file line number Diff line number Diff line change
@@ -15,10 +15,16 @@


def get_argparser():
if os.name == "nt":
default_db_file = os.path.expanduser("~\\artiq_browser.pyon")
else:
default_db_file = os.path.expanduser("~/.artiq_browser.pyon")

parser = argparse.ArgumentParser(description="ARTIQ Browser")
parser.add_argument(
"--db-file", default="artiq_browser.pyon",
help="database file for local browser settings")
"--db-file", default=default_db_file,
help="database file for local browser settings "
"(default: %(default)s)")
parser.add_argument("PATH", nargs="?", help="browse path or file")
verbosity_args(parser)
return parser
10 changes: 8 additions & 2 deletions artiq/frontend/artiq_dashboard.py
Original file line number Diff line number Diff line change
@@ -18,6 +18,11 @@


def get_argparser():
if os.name == "nt":
default_db_file = os.path.expanduser("~\\artiq_dashboard.pyon")
else:
default_db_file = os.path.expanduser("~/.artiq_dashboard.pyon")

parser = argparse.ArgumentParser(description="ARTIQ Dashboard")
parser.add_argument(
"-s", "--server", default="::1",
@@ -29,8 +34,9 @@ def get_argparser():
"--port-control", default=3251, type=int,
help="TCP port to connect to for control")
parser.add_argument(
"--db-file", default="artiq_dashboard.pyon",
help="database file for local GUI settings")
"--db-file", default=default_db_file,
help="database file for local GUI settings "
"(default: %(default)s)")
verbosity_args(parser)
return parser

13 comments on commit d4ba525

@jordens
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's not scatter stuff around too far. This will break quickly if you switch between different versions. Defaulting to ~ makes version-tracking this tedious and even then we should play nice with XDG and the rest and do os.path.join(site.getuserbase(), "artiq").

@sbourdeauducq
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The normal way GUI applications are run is via a desktop shortcut, and then the "current directory" is somewhat undefined. I'd like to gradually move the ARTIQ GUI tools from the "CLI tools that display windows" solution of 1.0 to fully-fledged GUI applications.

There should be some compatibility of that file across versions. And there is the --db-file option, which is more compatible with shortcuts than changing current directories.

What does XDG bring to the table, exactly? Anything more than cross-platform problems?

@jordens
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Desktop shortcuts have (on windows) a field precisely for this: to explicitly set the working directory. Why would that be not compatible? And setting the working directory is desirable in any case. Certainly for the browser. You would just duplicate information.

Littering dotfiles everywhere, (which are by the way not configuration files here but mere state dumps) is just bad practice. Don't do that unless they are actually configuration files. And even then XDG brings exactly this: standardization of paths. What cross platform problems would XDG bring? This is also exactly where python puts its files. Why would try something else and ignorantly just throw them into the windows home directory. What other application behaves that way?

If you just throw state dumps around globally, you also need to take care of migrating existing ones and getting rid of old and renamed ones.

There is zero compatibility if you just dump it as a dotfile into home. The system breaks instantly if e.g. a dock is renamed. Then using the same state dump with two different versions forgets and messes up the status each time you switch.

@sbourdeauducq
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This field is somewhat obscure and I'm not sure if there is an equivalent functionality in every Linux GUI environment. And what other GUI application requires you to set the current directory before you run it? The only one I can think of is gitk.

What is the workflow for the browser? Wouldn't it make sense to give it full filesystem access, and save the last filesystem position in the state file instead?

Examples of other applications that save config/state in ~: conda, bash, ssh, matplotlib, Qt Designer (Linux and Windows); X, subversion, Skype, cargo, d-bus, gnupg (Linux, maybe Windows). I don't care if it's ~ or ~/.config, we can use the latter on Linux. And I will take XDG seriously when Linux stops opening JPG files with Wine Internet Explorer and directories with Audacious by default.

This pyqtgraph dock bug is not present anymore since we switched to qt docks, and in general the GUI can deal with many cases of broken state files. Migrating those is desirable in any case.

@sbourdeauducq
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't care if it's ~ or ~/.config, we can use the latter on Linux.

and $APPDATA on Windows.

@jordens
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lots of applications that can show you a file selection dialog or a file system tree, reference that to the current working directory. Photo applications, file browsers etc. Not much obscure there.

GUI-wise, you would usually start the browser handing it a specific file or a specific directory to browse. Saving the last directory is probably more of a fallback.

The problem is that the GUI doesn't deal with new versions of these state dumps at all. Since it blindly and always saves that dump, every roundtrip between two versions loses state if something has changed.

AFAICT Matplotlib and Qt at least seem to have moved to XDG paths a while ago. The others seem to have valid reasons to disagree with the "X" or the "D" in XDG.
Do you feel XDG is responsible for your wine and audacious problems? That's sounds like holding matplotlib responsible if the data in a graph is fake.
Either complain loudly about tool X (e.g. conda) categorically whenever you see something you don't like or glorify it as a welcome reference for something you would like to do. Both don't mix well.

And ~/.local and %APPDATA/Python is exactly what site.userbase() gives you.

@sbourdeauducq
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do you start the browser? The GUI way is via right-clicking on a folder in a file manager and selecting a menu option. The file manager can pass the path as command line argument then, and you could also do artiq_browser . in the shell. When it is run without argument, take the last path.

Juggling versions will often require user intervention anyway, and there is --db-file for dealing with those special cases. Or just backup the old file when updating ARTIQ...

I'm not glorifying anything, .condarc (and .matplotlib) is already there, so simply it is consistent with (some of) the rest of the environment.

(And yes, xdg-open and friends routinely run grossly inappropriate applications. You may argue this is a different part of XDG, but I'm generally not impressed with it.)

@whitequark
Copy link
Contributor

@whitequark whitequark commented on d4ba525 Apr 16, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @jordens here, artiq_gui, as a desktop application, should use the XDG locations. Python has a proper library for that too, and it's of course in conda.

Examples of other applications that save config/state in ~: conda, bash, ssh, matplotlib, Qt Designer (Linux and Windows); X, subversion, Skype, cargo, d-bus, gnupg (Linux, maybe Windows).

cargo, conda, bash, ssh, matplotlib, subversion and gnupg are not desktop applications, so they are not subject to XDG (and cargo is additionally getting an option to use XDG because its massive caches should really live in ~/.local when you are developing Rust on a desktop).

Qt Creator stores its files in ~/.config/QtProject/QtCreator*; Skype uses ~/.config/Skype; so that's simply wrong.

X predates XDG by many years (naturally) and while I would argue that it should use XDG directories, too much code would break if that would be actually done.

(And yes, xdg-open and friends routinely run grossly inappropriate applications. You may argue this is a different part of XDG, but I'm generally not impressed with it.)

This has exactly zero things to do with XDG. xdg-open is a script that simply delegates to your desktop environment, in your case gvfs-open, so it is a GNOME bug. xdg- in xdg-open merely says that the name of the executable to open an appropriate file is standardized under XDG. Please, stop spreading disinformation about things you have not put even minimal effort to investigate.

@sbourdeauducq
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Qt Creator stores its files in ~/.config/QtProject/QtCreator*; Skype uses ~/.config/Skype; so that's simply wrong.

That must be new then or depending on other factors, in any case I do have ~/.Skype and ~/.designer, and the Win7-experimental VM does have C:\Users\User\.designer.

This has exactly zero things to do with XDG. xdg-open is a script that simply delegates to your desktop environment, in your case gvfs-open, so it is a GNOME bug.

And a KDE bug, and a Enlightenment bug, and...

@sbourdeauducq
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Python has a proper library for that too, and it's of course in conda.

Which does not work on Windows and requires lazy import + figuring out how to get Conda to automatically install it only on Linux while keeping artiq a noarch package.

What does XDG bring to the table, exactly? Anything more than cross-platform problems?

@whitequark
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in any case I do have ~/.Skype

I checked again and most of Skype's guts is in ~/.Skype whereas ~/.config/Skype contains just the Qt-internal parts, i.e. window positioning. Proprietary software doesn't care about standards, more at 11.

and ~/.designer, and the Win7-experimental VM does have C:\Users\User.designer.

Yes. There seems to be some outdated plugin interface in Qt Designer which does this. The rest of configuration is stored where it should be:

whitequark@raidho:~$ find ~/.config | grep -i qtcreator
/home/whitequark/.config/QtCreatorrc
/home/whitequark/.config/QtProject/qtcreator
/home/whitequark/.config/QtProject/qtcreator/codestyles
/home/whitequark/.config/QtProject/qtcreator/codestyles/Cpp
/home/whitequark/.config/QtProject/qtcreator/codestyles/Cpp/qt2.xml
/home/whitequark/.config/QtProject/qtcreator/ssh-hostkeys
/home/whitequark/.config/QtProject/qtcreator/macros
/home/whitequark/.config/QtProject/qtcreator/default.qws
/home/whitequark/.config/QtProject/qtcreator/styles
/home/whitequark/.config/QtProject/qtcreator/styles/customized.xml
/home/whitequark/.config/QtProject/qtcreator/qnx
/home/whitequark/.config/QtProject/qtcreator/qnx/qnxconfigurations.xml
/home/whitequark/.config/QtProject/qtcreator/qnx/bbndkconfigurations.xml
/home/whitequark/.config/QtProject/qtcreator/cmaketools.xml
/home/whitequark/.config/QtProject/qtcreator/json
/home/whitequark/.config/QtProject/qtcreator/generic-highlighter
/home/whitequark/.config/QtProject/qtcreator/mimetypes
/home/whitequark/.config/QtProject/qtcreator/mimetypes/modifiedmimetypes.xml
/home/whitequark/.config/QtProject/qtcreator/qtversion.xml
/home/whitequark/.config/QtProject/qtcreator/toolchains.xml
/home/whitequark/.config/QtProject/qtcreator/qbs
/home/whitequark/.config/QtProject/qtcreator/qbs/profiles
/home/whitequark/.config/QtProject/qtcreator/qbs.conf
/home/whitequark/.config/QtProject/qtcreator/devices.xml
/home/whitequark/.config/QtProject/qtcreator/helpcollection.qhc
/home/whitequark/.config/QtProject/qtcreator/profiles.xml
/home/whitequark/.config/QtProject/qtcreator/debuggers.xml
/home/whitequark/.config/QtProject/QtCreator.db
/home/whitequark/.config/QtProject/QtCreator.conf
/home/whitequark/.config/QtProject/QtCreator.ini

And a KDE bug, and a Enlightenment bug, and...

And how is this relevant to XDG?

Which does not work on Windows and requires lazy import + figuring out how to get Conda to automatically install it only on Linux while keeping artiq a noarch package.

Yes, this is an actual problem.

@sbourdeauducq
Copy link
Member Author

@sbourdeauducq sbourdeauducq commented on d4ba525 Apr 16, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And how is this relevant to XDG?

The user problem is: opening a file with the right application. Instead of managing file associations correctly and once and for all, XDG delegates to various environments that bring half a dozen incompatible implementations and none of them works correctly. Where is the betterment? This does not look like a strong standard to me.

@whitequark
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where is the betterment?

Without XDG, every application that wants to open files portably would have to reimplement xdg-open, and it would work even worse than it is now. In any case, does artiq_gui want to open files?

Please sign in to comment.