My trouble with the current implementation of the properties file is
understanding the code that creates them. perhaps its my inexperience
but it seems to be pretty complex, and the way SciTE uses them for
preferences/settings is, to me, pretty unintuitive.
Maybe I'll look more into how properties are handled, but my first
looks at them left me pretty lost.
Message: 6
Date: Sun, 05 Jun 2005 23:11:11 -0700
From: Robert Roessler <[EMAIL PROTECTED]>
Subject: Re: [scintilla] Database useage for storing preferences
To: Discussion of the Scintilla editing component
<[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Josh Phillips wrote:
Sqlite can easily be embedded into an application and provides an easy
and intuitive means for storing and retrieving properties and other user
settings and when embedded takes only 250kb or so.
Yes, but [to me, anyway] that still seems a bit heavyweight (or
overkill) for this task - both in terms of file/memory footprint and
"excess" functionality/API...
Don't get me wrong - SQLite seems like a good mix of size, features
and performance, and I have been waiting for a while for something
cool to use it on - but presumably more than simple accessing and
persistence of app options. :)
It might also make for an easy implementation for property sheets rather
than having the user required to manually edit a configuration file. The
same could be used for calltips etc.
I am not following you here - the "barrier" to having more graphical
ways of dealing with options has always been the programming of the
GUI itself - or so I thought... or is there some tool one uses with
SQLite that magically generates well laid-out property sheets directly
from your DB schema?
Robert Roessler
[EMAIL PROTECTED]
http://www.rftp.com
------------------------------
Message: 7
Date: Mon, 06 Jun 2005 17:14:24 +0800
From: Kein-Hong Man <[EMAIL PROTECTED]>
Subject: Re: [scintilla] Database useage for storing preferences
To: Discussion of the Scintilla editing component
<[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Robert Roessler wrote:
Josh Phillips wrote:
Sqlite can easily be embedded into an application and provides an easy
and intuitive means for storing and retrieving properties and other
user settings and when embedded takes only 250kb or so.
Yes, but [to me, anyway] that still seems a bit heavyweight (or
overkill) for this task - both in terms of file/memory footprint and
"excess" functionality/API...
Well Josh, if you can get it past Neil into CVS, I'll seriously
consider worshipping you. :-) :-) OTOH, this seems to be more of a
topic for SciTE.
[snip]
It might also make for an easy implementation for property sheets
rather than having the user required to manually edit a configuration
file. The same could be used for calltips etc.
I am not following you here - the "barrier" to having more graphical
ways of dealing with options has always been the programming of the GUI
itself - or so I thought... or is there some tool one uses with SQLite
that magically generates well laid-out property sheets directly from
your DB schema?
Existing *.properties files on SciTE are: Easy to understand,
copy, modify, cherry-pick, customize, maintain, edit, update, ...
I sure wouldn't want to hack a DB file when something goes wrong.
I like my freedom to poke at the critter's entrails when there is
a need for it.
Besides, if the proposal is indeed related to how SciTE handles
things, bear in mind that SciTE not targeted at the average home
user, it's more for the average developer. There are other
Scintilla-based text editors that target less sophisticated users.
Ultimately, the question is: Does GUI configuration save users
time and effort? I'll humbly put my vote in the 'No' bin.
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
