Wed 04 Mar 2009 01:01:07 AM UTC, comment #14:
I've pushed a changeset which does this for dialog boxes also. Closing this item.
|
Tue 03 Mar 2009 11:53:01 AM UTC, comment #13:
On further reflection, gconf provides more than we actually need, at least for now. So I've pushed an implementation which uses simple GKeyFile files. But I've wrapped it in a API which would be simple to re-implement using gconf should we decide to do so at a later date.
Right now, it should work for the data, syntax and output windows. The dialog boxes are yet to be done.
|
Fri 27 Feb 2009 05:08:22 PM UTC, comment #12:
The developers of gnumeric told me that they use a special version of gconf, plataform dependent. We should take a look on that.
|
Wed 25 Feb 2009 05:28:18 AM UTC, comment #11:
One problem is using gconf on Windows. Compile gconf requires dbus, and I don't know if will be possible to compile it to Windows. I will give it a try. We can also see how developers of other softwares do it on windows, like gimp and gnumeric.
|
Tue 24 Feb 2009 07:11:24 AM UTC, comment #10:
>I'd like to use Gconf for these kind of user preference settings,
>since it's a lot more flexible and easier to code. But this means
>another library to depend upon. We'd have to just use hard coded
>defaults if Gconf is not available. What do people think?
There is a lot of software that already uses Gconf: "apt-cache rdepends libgconf2-4" lists over 500 packages! So I think that the burden of adding this library dependency, if any, would be on the packager; anyone who uses practically any GNOME app already has gconf installed.
Increasingly, I don't think that we can expect end users to be able to build PSPP themselves anyway.
IOW, this sounds fine to me.
|
Tue 24 Feb 2009 07:04:10 AM UTC, comment #9:
I'd like to use Gconf for these kind of user preference settings, since it's a lot more flexible and easier to code. But this means another library to depend upon. We'd have to just use hard coded defaults if Gconf is not available. What do people think?
|
Thu 08 Jan 2009 03:37:30 AM UTC, comment #8:
I noticed that Glib has functions for determining where config, cache, and user data should go:
http://library.gnome.org/devel/glib/unstable/glib-Miscellaneous-Utility-Functions.html
|
Sun 28 Dec 2008 06:18:07 PM UTC, comment #7:
You raise an interesting question. The reason for the existence of this spec (from my understanding) is to reduce the insane amount of hidden folders cluttering the home dir. I personally have something like 130 of them, and there is no distinction between "important" stuff (data, maybe settings) and unimportant stuff (cache, recently used items, etc).
I've searched a bit, and it seems someone pretty much asked the same question on the freedesktop mailing lists http://www.mail-archive.com/xdg@lists.freedesktop.org/msg04612.html
I'm not disagreeing on you on the "wtf .local/share" argument, I actually haven't quite understood their reasoning as exposed through that mailing list thread.
|
Sun 28 Dec 2008 05:30:42 PM UTC, comment #6:
>I do think that you should try conforming to the XDG directory
>spec (http://standards.freedesktop.org/basedir-spec/latest/)
>instead of placing stuff in $HOME/.pspp, however.
This specification is either bizarre or under-explained. As a user I do not want to store my data files in $HOME/.local/share. Why would I? And why should I have to set an environment variable to override that bizarre default?
>This is the perfect time to "do it right the first time"
I'm all in favor of conforming to relevant standards but I don't understand this one at all.
|
Sun 28 Dec 2008 04:06:27 PM UTC, comment #5:
Indeed. I thought it was just the list of recent files.
I do think that you should try conforming to the XDG directory spec (http://standards.freedesktop.org/basedir-spec/latest/) instead of placing stuff in $HOME/.pspp, however. This is the perfect time to "do it right the first time" (since it seems PSPPire doesn't yet save user data it seems).
I first heard about the xdg desktop dirs thing through this post, which does a good job at explaining the issue/challenges that this spec addresses: http://ploum.frimouvy.org/?184-cleaning-user-preferences-keeping-user-data
|
Sun 28 Dec 2008 05:29:43 AM UTC, comment #4:
>The gui currently saves a pspp.jnl file in my home directory (it's
>not even hidden). If kept, this particular file should at least go
>in $XDG_CACHE_HOME/pspp/ and be named something clearer, maybe
>"recent-files.jnl" or something.
I don't think that "recent-files.jnl" would be a particularly good name for it, because pspp.jnl is not, in general, just a list of recently opened files. Instead, it's a journal of all of the commands that PSPP(IRE) has executed recently, including e.g. statistical analysis commands.
The home directory (or current directory, I think, actually) is probably not the best place for it, though, especially for the GUI. It would probably make sense to save this in $HOME/.pspp.jnl or $HOME/.pspp/pspp.jnl, or just to keep it in a pane or a window and allow the user to save it manually.
|
Sun 28 Dec 2008 04:48:45 AM UTC, comment #3:
The gui currently saves a pspp.jnl file in my home directory (it's not even hidden). If kept, this particular file should at least go in $XDG_CACHE_HOME/pspp/ and be named something clearer, maybe "recent-files.jnl" or something.
However, the ideal way to do it would be this: http://standards.freedesktop.org/recent-file-spec/recent-file-spec-0.2.html
|
Mon 24 Nov 2008 03:11:00 AM UTC, comment #2:
Although it is python, maybe this could be of some help to figure out the logic:
http://code.google.com/p/specto/source/browse/trunk/spectlib/notifier.py
(between lines 555 and 596).
For actually storing the data, there is the option of using gconf under gnome, or maybe a config file (ini style? xml style?) in the XDG config directory (for that, see: http://standards.freedesktop.org/basedir-spec/latest/ or http://standards.freedesktop.org/basedir-spec/latest/ar01s03.html )?
|
Sun 23 Nov 2008 11:14:14 PM UTC, comment #1:
Currently, the gui doesn't save any user preference information. Presumably there is a recommended gtk way of doing this, but so far I haven't investigated this.
Any suggestions will be welcome.
|
Sun 23 Nov 2008 07:02:36 PM UTC, original submission:
Please automatically save the dimensions for all windows that can be resized by the user; at the same time, some currently not-resizable windows could benefit from the ability to be resized.
The reasons are
- scrolling sucks
- tiny windows are not as useful as they could be, on high resolution screens (which are getting increasingly common)
- it makes your application more polished
Among these (but not the only ones, I presume):
- the main window
- the value labels dialog
- utilities > variables
- utilities > data file comments
- dialogs in the Analyze menu
When restoring the size of the windows, the window must initially be hidden, then the size is set, and then the window is shown; the reason for this is for HIG compliance, the user should not see windows flashing/resizing, it should be invisible to the naked eye.
|