Forum: Ruby FXRuby - Howto remember some default settings as specified b

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
unknown (Guest)
on 2006-05-26 15:20
(Received via mailing list)
Dear all,

in an FXRuby GUI, I want to give the user many choices and I am
searching for
a way to let FXRuby remember these upon the next start of the GUI
application.

To be a bit more concrete, imagine a program that has a text widget,  so
that
the user can enter some text and then choose language it should be
translated
from from several buttons that can be ticked.

Now, I know how to set some default (say English-French), so that this
appears
everytime the GUI is started.
But I would like to give the user the opportunity to change this to
Chinese-Japanese,
and save that choice, so that the default is set to this choice when the
program
is opened next time.
I have many such choices, so this might make the GUI program more
comfortable
to work with.
How could that be done ?

Thank you.

Best regards,

Axel
Meinrad Recheis (Guest)
on 2006-05-26 15:42
(Received via mailing list)
On 5/26/06, Nuralanur@aol.com <Nuralanur@aol.com> wrote:
> Dear all,
>
> in an FXRuby GUI, I want to give the user many choices and I am  searching for
> a way to let FXRuby remember these upon the next start of the GUI
> application.
[...]

there is no such mechanism implemented in fox / fxruby (at least i
don't know of any)
you 'll need to hack your own. i had this problem too and wrote my own
module for remembering usersettings.

-- henon
Ryan Leavengood (Guest)
on 2006-05-26 16:29
(Received via mailing list)
On 5/26/06, Nuralanur@aol.com <Nuralanur@aol.com> wrote:
>
> I have many such choices, so this might make the GUI program more  comfortable
> to work with.
> How could that be done ?

Store the user settings in a Hash object and then save that to YAML
when the user changes options (or when the program exits...though that
means crashes result in non-saved settings.) When the program starts,
see if the user settings file exists, if it does load it, otherwise
load the default settings. Then apply the settings to the GUI
elements.

Ryan
Joel VanderWerf (Guest)
on 2006-05-26 19:18
(Received via mailing list)
Nuralanur@aol.com wrote:
> Dear all,
>
> in an FXRuby GUI, I want to give the user many choices and I am  searching for
> a way to let FXRuby remember these upon the next start of the GUI
> application.

This is what I use with FXRuby (but it's not dependent on FXRuby or even
on GUI):

http://redshift.sourceforge.net/preferences/

A simple example (in terms of a hypothetical GUI lib):

  require 'preferences'

  PREFS = Preferences.new("/tmp/prefs")

  class Window
    attr_accessor :x, :y
    def initialize
      PREFS.register_pref_key self, "my app/window"
      PREFS.register_pref_var self, :x, :y => "default_y"
    end

    def run
      @x = 7 # emulate user's interaction
    end
  end

  Window.new.run
  PREFS.save

An example is in examples/foursplit-prefs.rb. It remembers the positions
of two four-splitters.

It includes an optional method to make a reasonable cross-platform guess
of where preference files should be (e.g. APPDATA on win32).

The storage format is YAML, of course.
Joel VanderWerf (Guest)
on 2006-05-26 19:21
(Received via mailing list)
Nuralanur@aol.com wrote:
> Dear all,
>
> in an FXRuby GUI, I want to give the user many choices and I am  searching for
> a way to let FXRuby remember these upon the next start of the GUI
> application.

This is what I use with FXRuby (but it's not dependent on FXRuby or even
on GUI):

http://redshift.sourceforge.net/preferences/

A simple example (in terms of a hypothetical GUI lib):

  require 'preferences'

  PREFS = Preferences.new("/tmp/prefs")

  class Window
    attr_accessor :x, :y
    def initialize
      PREFS.register_pref_key self, "my app/window"
      PREFS.register_pref_var self, :x, :y => "default_y"
    end

    def run
      @x = 7 # emulate user's interaction
    end
  end

  Window.new.run
  PREFS.save

A longer example that uses FXRuby is in examples/foursplit-prefs.rb. It
remembers the positions of two four-splitters.

It includes an optional method to make a reasonable cross-platform guess
of where preference files should be (e.g. APPDATA on win32).

The storage format is YAML, of course.
Lyle Johnson (Guest)
on 2006-05-29 16:47
(Received via mailing list)
On 5/26/06, Nuralanur@aol.com <Nuralanur@aol.com> wrote:

> in an FXRuby GUI, I want to give the user many choices and I am  searching for
> a way to let FXRuby remember these upon the next start of the GUI
> application.

FOX's built-in registry stuff is probably the easiest choice to use.
It was a little disturbing to see so many responses that didn't point
out that option. Anyways, for more information, read this:

    http://www.fox-toolkit.com/registry.html

Hope this helps,

Lyle
Joel VanderWerf (Guest)
on 2006-05-29 23:27
(Received via mailing list)
Lyle Johnson wrote:
>
>    http://www.fox-toolkit.com/registry.html
>
> Hope this helps,
>
> Lyle

I gave up on FXRegistry and its parent FXSettings (and wrote the
Preferences lib) because of the attached, from FXSettings.cpp. Note
particularly the 2000 byte maximum on entry values.

YAML is much more flexible. It handles the value parsing for you, which
is a minor benefit for scalar types (numbers/booleans/strings/Times/etc)
but especially nice if you have complex values, such as lists of things
or hashes. With YAML, you can have hierarchical values, which are good
for remembering settings on nested panes, or dependent dialog windows
and their fields/panes.

For a simple application these differences may not matter.

OTOH, FXRegistry can put things in the Windows Registry if that's the
way you want to go, for some reason. Also, if you need to interoperate
with registry entries from C++ based Fox apps, FXRegistry is the only
choice. Conversely, this will make it harder to interoperate with other
ruby code that doesn't know about FXRuby.

/*
  Notes:

  - Format for settings database file:

    [Section Key]
    EntryKey=string-with-no-spaces
    EntryKey="string\nwith a\nnewline in it\n"
    EntryKey=" string with leading and trailing spaces and \"embedded\"
in it  "
    EntryKey=string with no leading or trailing spaces

  - EntryKey may is of the form "ali baba", "ali-baba", "ali_baba", or
"ali.baba".

  - Leading/trailing spaces are NOT part of the EntryKey.

  - FXSectionDict should go; FXSettings should simply derive from
FXDict.

  - Escape sequences now allow octal (\377) as well as hex (\xff) codes.

  - EntryKey format should be like values.

  - Extensive error checking in unparseFile() to ensure no settings data
is
    lost when disk is full.

*/

#define MAXBUFFER 2000
#define MAXNAME   200
#define MAXVALUE  2000
Lyle Johnson (Guest)
on 2006-05-30 00:58
(Received via mailing list)
On 5/29/06, Joel VanderWerf <vjoel@path.berkeley.edu> wrote:

> I gave up on FXRegistry and its parent FXSettings (and wrote the
> Preferences lib) because of the attached, from FXSettings.cpp. Note
> particularly the 2000 byte maximum on entry values.

Thanks for pointing that out, I wasn't aware of it. That one reason
alone (including the associated risk of a buffer overflow) is enough
to dissuade me from using FXRegistry. And I of course agree with your
comments about YAML.
Joel VanderWerf (Guest)
on 2006-05-30 01:29
(Received via mailing list)
Lyle Johnson wrote:
> On 5/29/06, Joel VanderWerf <vjoel@path.berkeley.edu> wrote:
>
>> I gave up on FXRegistry and its parent FXSettings (and wrote the
>> Preferences lib) because of the attached, from FXSettings.cpp. Note
>> particularly the 2000 byte maximum on entry values.
>
> Thanks for pointing that out, I wasn't aware of it. That one reason
> alone (including the associated risk of a buffer overflow) is enough
> to dissuade me from using FXRegistry. And I of course agree with your
> comments about YAML.

IIRC it doesn't cause buffer overflow, it just truncates the data. But
that can cause mysterious bugs if you're not expecting it.
This topic is locked and can not be replied to.