bugPSPP - Bugs: bug #24907, remember all window and dialog...

 
 

bug #24907: remember all window and dialog sizes

Submitter:  -Deleted Account- <kiddo>
Submitted:  Sun 23 Nov 2008 07:02:36 PM UTC
   
 
Category:  Graphical User Interface Severity:  5 - Average
Status:  Fixed Assigned to:  None
Open/Closed:  Closed Release:  None
Effort:  0.00
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

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.

John Darrington <jmd>
Group administrator
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.

John Darrington <jmd>
Group administrator
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.

Michel Boaventura <michelboaventura>
Group Member
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.

Michel Boaventura <michelboaventura>
Group Member
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.

Ben Pfaff <blp>
Group administrator
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?


John Darrington <jmd>
Group administrator
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

Ben Pfaff <blp>
Group administrator
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.

-Deleted Account- <kiddo>
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.

Ben Pfaff <blp>
Group administrator
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

-Deleted Account- <kiddo>
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.

Ben Pfaff <blp>
Group administrator
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

-Deleted Account- <kiddo>
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 )?

-Deleted Account- <kiddo>
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.

John Darrington <jmd>
Group administrator
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.

-Deleted Account- <kiddo>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by michelboaventura (Posted a comment)
  • -email is unavailable- added by blp (Posted a comment)
  • -email is unavailable- added by jmd (Posted a comment)
  • -email is unavailable- added by kiddo (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-03-04 jmd StatusNone Fixed
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code