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:
Dennis
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 how
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 functions are not
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 with how
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.
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
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 options, which
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
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 change
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
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 and
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
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 might
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. Beginner
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
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
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
17 matches
Mail list logo
