[Gd-chatter] [Bug 7259] The settings module of the system library is only implemented for Win32

[bugzilla-daemon at gwydiondylan.org]

http://www.gwydiondylan.org/cgi-bin/bugzilla/show_bug.cgi?id=7259


housel at acm.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         OS/Version|FreeBSD                     |All




------- Comment #1 from housel at acm.org  2006-05-10 07:13 -------
Today's discussion on IRC:

<housel> [23:08] do you think anyone would object if <settings> were
         implemented using GConf2 on posix systems?
<hannes__> [23:13] hmm, what is stored in <settings>? And how is it done now?
           I'm not sure depending on Gconf2 is a good idea...
<hannes__> [23:18] hmm, looks like "Open Dylan" and the build-script.. or is
           there more info we use from <settings> subclasses?
<housel> [23:18] All sorts of environment stuff is stored in settings
<housel> [23:18] It doesn't work at all on POSIX at the moment though
<housel> [23:19] it uses dummy-settings.dylan, which throws any settings
         changes away
<hannes__> [23:21] *browsing windows registry to look which settings are
           stored n win32*
<hannes__> [23:34] hmm, I'd guess a trivial key:value file in
           ~/.opendylan.conf would do it for now... with a self-written
           parser... also, human-editable with any text editor... or does
           gconf provide more than that (alternatively, a dood-written config
           would also be ok, if there would be a config shell)
<housel> [23:37] the dummy-settings file already contains the start of a
         scheme for storing settings in ~/.settings or something similar
<housel> [23:38] I started some work on finishing that
<housel> [23:38] But, it's subject to cross-thread and cross-program conflicts
<housel> [23:39] GConf wouldn't have that problem
<hannes__> [23:41] hmm, cross-thread and cross-platform issues for writing the
           same setting key & value at the same time?
<housel> [23:41] yes
<housel> [23:47] DOOD doesn't do file locking, does it?
<hannes__> [23:50] no, well, a simple .opendylan.conf.lock file would do
           that...
<hannes__> [23:54] oh, and it keeps a dood-corrupted boolean, which it sets to
           #t at the beginning of commit and to #f if it successfully wrote
           it. if not, it calls dood-restore-state...
<housel> [23:58] dood already depends on library system, we can't introduce a
         dependency loop
<hannes__> [23:59] yes, that's true. so dood is not an option
<housel> [23:59] it would have to be built on the bare metal (streams +
         file-system)
<andreas> [00:22] What's the rationale for settings living in system?
<housel> [00:31] I'm not sure
<andreas> [00:36] And if we implement the settings as they are using gconf, we
          make every Dylan program depending on system depend on gconf, which
          I think would be excessive.
<housel> [00:36] yes, perhaps
<housel> [00:37] but it might be reasonable if system were moved out into a
         separate library
<andreas> [00:37] We could make system export the interface, and then some
          other library actually implement it using DOOD or the registry.
<housel> [00:38] right
<housel> [00:40] that may be the best way... leaving just dummy-settings in
         system, and letting apps import whatever library they want for a real
         implementation
<hannes__> [00:41] yes


-- 
Configure bugmail: http://www.gwydiondylan.org/cgi-bin/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.