Am Sonntag, 1. April 2007 18:30 schrieb David Reveman:
> On Sun, 2007-04-01 at 01:39 +0200, Dennis Kasprzyk wrote:
> > Am Samstag, 31. März 2007 10:12 schrieben Sie:
> > > On Thu, 2007-03-29 at 17:23 +0200, Dennis Kasprzyk wrote:
> > > > Am Donnerstag, 29. März 2007 11:02 schrieb David Reveman:
> >
On Sun, 2007-04-01 at 01:39 +0200, Dennis Kasprzyk wrote:
> Am Samstag, 31. März 2007 10:12 schrieben Sie:
> > On Thu, 2007-03-29 at 17:23 +0200, Dennis Kasprzyk wrote:
> > > Am Donnerstag, 29. März 2007 11:02 schrieb David Reveman:
> > > > Dennis Kasprzyk and I have been discussing some changes to
Am Samstag, 31. März 2007 10:12 schrieb David Reveman:
> On Thu, 2007-03-29 at 17:23 +0200, Dennis Kasprzyk wrote:
> > Am Donnerstag, 29. März 2007 11:02 schrieb David Reveman:
> > > Dennis Kasprzyk and I have been discussing some changes to how options
> > > are initialized.
> > >
> > > Problems w
On Thu, 2007-03-29 at 17:23 +0200, Dennis Kasprzyk wrote:
> Am Donnerstag, 29. März 2007 11:02 schrieb David Reveman:
> > Dennis Kasprzyk and I have been discussing some changes to how options
> > are initialized.
> >
> > Problems with how options are currently initialized.
> >
> > 1. Helper functi
Dennis Kasprzyk wrote:
Am Freitag, 30. März 2007 17:48 schrieben Sie:
We could always add an option 5 where there a getOptionMetaData
function which the storage plugins could be responsible for wrapping
They could then choose how to store this information.
In this system a plugin developer
On Thu, 2007-03-29 at 16:56 +0100, Mike Dransfield wrote:
> David Reveman wrote:
> > Dennis Kasprzyk and I have been discussing some changes to how options
> > are initialized.
> >
> > Problems with how options are currently initialized.
> >
> > 1. Helper functions are not used to initialize option
Dennis Kasprzyk wrote:
Am Donnerstag, 29. März 2007 18:33 schrieben Sie:
Dennis Kasprzyk wrote:
The problem is that we already have additional data in the plugins. So we
should be consistent here and remove also the long/short decriptions of
the option struct and or the plugin vtable an
Dennis Kasprzyk wrote:
Do you also want a
CompOptionTypeExecutable,
Thats hardly ever needed, when it is used, it normally refers
to a command rather than directly to an executable.
If you wanted this then you could always create a file type and
have it parse the mime type etc.
CompOptionT
We could set up bcop to generate the code for a library for each
plugin that just contains the functions required to get the settings.
Furthermore these settings could be represented through some
hypothetical CompOptionMetadata struct which could contain all the
useful metadata we want.
With some
Danny Baumann wrote:
I disagree. There are different usage models, reflected best by having
different settings managers. Beginner users may want an
as-simple-as-possible settings manager (such as desktop-effects),
average users may want a settings manager which provides some more
settings (such a
Dennis Kasprzyk wrote:
The problem is that we already have additional data in the plugins. So we
should be consistent here and remove also the long/short decriptions of the
option struct and or the plugin vtable and move it to an additional file or
have everything in the plugin. A mixture of
Hi,
> I think in the long term, the autogenerated settings managers
> will be replaced with hard coded user friendly ones, this will
> leave all of these extra attributes with nowhere to go.
I disagree. There are different usage models, reflected best by having
different settings managers. Beginn
Travis Watkins wrote:
On 3/29/07, Mike Dransfield <[EMAIL PROTECTED]> wrote:
> 2. No convenient way to get the initial value of an option once it's
> been modified.
>
No, this was my problem when writing ini.
The way I see it is that gconf should be able to revert to
the default easily, ini mi
Am Donnerstag, 29. März 2007 17:54 schrieb Bellegarde Cedric:
> Le jeudi 29 mars 2007, Dennis Kasprzyk a écrit :
> > Currently there are two types of configuration tools. Some with fixed
> > functionality and some autogenerated. To improve the quality of the
> > autogenerated tools I would like to
On 3/29/07, Mike Dransfield <[EMAIL PROTECTED]> wrote:
> 2. No convenient way to get the initial value of an option once it's
> been modified.
>
No, this was my problem when writing ini.
The way I see it is that gconf should be able to revert to
the default easily, ini might need some work.
I
Le jeudi 29 mars 2007, Dennis Kasprzyk a écrit :
> Currently there are two types of configuration tools. Some with fixed
> functionality and some autogenerated. To improve the quality of the
> autogenerated tools I would like to make this proposal about additional
> values in the CompOption struct
David Reveman wrote:
Dennis Kasprzyk and I have been discussing some changes to how options
are initialized.
Problems with how options are currently initialized.
1. Helper functions are not used to initialize options, which means that
if we make a change to the option structure, all option init
Dennis Kasprzyk wrote:
Additions to the CompOption struct:
char * group/char * subgroup : Ability to group sets of options and to give
this sets a name.
I think that subgroup (and probably group) are excessive
and they lead to the plugin writer designing the UI which
is not right. From wha
Am Donnerstag, 29. März 2007 11:02 schrieb David Reveman:
> Dennis Kasprzyk and I have been discussing some changes to how options
> are initialized.
>
> Problems with how options are currently initialized.
>
> 1. Helper functions are not used to initialize options, which means that
> if we make a
Dennis Kasprzyk and I have been discussing some changes to how options
are initialized.
Problems with how options are currently initialized.
1. Helper functions are not used to initialize options, which means that
if we make a change to the option structure, all option initialization
code needs t
20 matches
Mail list logo