This is the mail archive of the
mailing list for the Cygwin XFree86 project.
Re: XWin design suggestion
- From: Alexander Gottwald <alexander dot gottwald at s1999 dot tu-chemnitz dot de>
- To: cygwin-xfree at cygwin dot com
- Date: Tue, 6 May 2003 11:02:02 +0200 (MEST)
- Subject: Re: XWin design suggestion
- Reply-to: cygwin-xfree at cygwin dot com
On Mon, 5 May 2003, Sam Edge wrote:
> Personally I think XWin.exe-specific stuff shouldn't be in XF86Config
Why not? Setting multiwindow-mode in the configfile is IMO an easy way
to setup the behaviour of the xserver.
> For Windows applications, yes.
> For a POSIX-style program that stores
> settings in a text file, the INI-file format is as good as any. If
> someone does choose to write a Cygwin-specific program that uses this
> format for a file in /etc or $HOME, then why not use the Win32
> INI-file API?
I don't want to argue about the format of the file. It's more about the
need of this extra file. And for such value like window positions there
is an very easy to use storage and this is the registry.
> > echo "Some value" > /proc/registry/HKEY_CURRENT_USER/Software/Cygnus/XFree86/TweakMe
> > would be cool *g*
> LOL. How about rm -fr /proc/registry/HKEY_CURRENT_USER/* too? ;-)
> > I dislike having to rewrite a file where window positions
> > are stored from within Xwin because of complexity
> > - race conditions
> > - multi-user usage
> > - multi-instance usage
> > - merging of options from commandline, user config and XF86Config
> > - merging into existing code
> > - speed (parsing the file when a value is needed) vs complexity
> > (parsing the file at startup and access values in memory)
> The Win32 registry API doesn't prevent the listed problems from
> occurring either, except by using write-locking on the keys. There's
> no reason why an application can't use file-locking to do the same for
> a text-based data store.
Most of the complexity is solved in the win32 layer. We don't have to
take care of concurrent writes (Those, that would corrupt data. There
will always be one value that is overwritten and one that is kept).
Rewriting the database and parsing is done in the win32 layer,
> Many applications read and modify their text-based configuration or
> state files without these issues becoming a problem. Many ***X
> applications do this for both user-modified configuration and for
> programmatically maintained state. For example ncftp, openbox, bash
> (.bash_history), vim, nedit, mc, ... - all of which work fine under
vim or bash store the history in a textfile. This is done right before
the program quits. Adding the dump of the configurations just before
the Xserver resets is more complicated than storing the values in
the registry right after they were modified.
http://www.gotti.org ICQ: 126018723