Taking over some task from the TODO list
Adrian Perez de Castro
Hello!
I would like to contribute by picking an easy task from the TODO list,
and I think that «Store configuration issues locally [...]» is a good
candidate.
As far as I know, there two are options:
1. Using GKeyFile [1] to save/load a file under ~/.config -- This
matches better the FreeDesktop specs [2]
2. Using GConf and letting it handle configuration stuff.
Well, and then there's dconf [3], but (again AFAIK) it is not being
widely adopted...
Personally, I see using nicer GKeyFile because it would be one less
dependency, and using human-readable text files follows the Unix
philosophy. On the other hand, using GConf allows for being
notified about when system-wide settings change e.g. for changing
toolbar styles and the like on the fly when the user changes things in
the GNOME configuration dialogs.
What do you think? Which solution fits Frogr the better?
--
[1]
http://library.gnome.org/devel/glib/stable/glib-Key-value-file-parser.html
[2] http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html
[3] http://live.gnome.org/dconf
--
Adrian Perez de Castro <ape...@igalia.com>
Igalia - Free Software Engineering
Mario Sanchez Prada
Mario Sanchez Prada
>
> I would like to contribute by picking an easy task from the TODO list,
Great!
> and I think that «Store configuration issues locally [...]» is a good
> candidate.
Yep, that's actually a very good candidate, as it's one of the things I
guess would be nice to have implemented by version 0.1, and as I'm
working on another task right now ("details window").
> As far as I know, there two are options:
>
> 1. Using GKeyFile [1] to save/load a file under ~/.config -- This
> matches better the FreeDesktop specs [2]
I like this choice. Actually I was thinking on this way to implement it
as well :-)
> 2. Using GConf and letting it handle configuration stuff.
>
> Well, and then there's dconf [3], but (again AFAIK) it is not being
> widely adopted...
I'd let this out of the game, at least while there're no strong reasons
to do it so.
> Personally, I see using nicer GKeyFile because it would be one less
> dependency, and using human-readable text files follows the Unix
> philosophy. On the other hand, using GConf allows for being
> notified about when system-wide settings change e.g. for changing
> toolbar styles and the like on the fly when the user changes things in
> the GNOME configuration dialogs.
Agreed. I strongly prefer using a configuration file for this rather
than storing things through gconf. Is not about having less dependencies
only, which is truly a good thing, but about having extra flexibility
for storing things in a most sophisticated way (xml file, for instance).
And here it comes up a nice point of mini-discussion... what do you
think about using an xml file instead a GKeyFile to store configuration?
I understand at this point, when we could be interested only in just
saving some very simple data (frob and auth tokens for just one flickr
account only), using a GKeyFile would be more than enough... but
thinking in the future, perhaps an XML file could give us extra
potential to store more information (e.g. think of adding multi-user
support to the app, therefore storing multiple configuration values
depending on the user), and choosing the xml file from the very
beginning would avoid having to maintaint backwards compatibility in the
future with the GKeyFile.
But perhaps I'm just thinking to far in the horizon and it does not make
sense at all going ahead with the xml file and the GKeyFile idea would
be just perfect.
> What do you think? Which solution fits Frogr the better?
I think (1) is the way to go, just some doubts choosing the GKeyFile or
and xml file for that, so woud love to hear your opinion on this.
Btw, do not worry about the libxml dependency: it's already in the code
because of libflickcurl, so no extra dependency would be added.
Thanks!
Mario
Mario Sanchez Prada
starting to write the answer :P
Adrian Perez de Castro
> > and I think that «Store configuration issues locally [...]» is a good
> > candidate.
>
> Yep, that's actually a very good candidate, as it's one of the things I
> guess would be nice to have implemented by version 0.1, and as I'm
> working on another task right now ("details window").
Ok, I will try to have working code anytime soon for saving account
authentication tokens and settings for the details window (default
license, visibility and the like)
> > As far as I know, there two are options:
> >
> > 1. Using GKeyFile [1] to save/load a file under ~/.config -- This
> > matches better the FreeDesktop specs [2]
>
> I like this choice. Actually I was thinking on this way to implement it
> as well :-)
Great :)
> And here it comes up a nice point of mini-discussion... what do you
> think about using an xml file instead a GKeyFile to store configuration?
>
> I understand at this point, when we could be interested only in just
> saving some very simple data [...] perhaps an XML file could give us extra
> potential to store more information (e.g. think of adding multi-user
> support to the app [...]
What about using a section per user profile? For the record, en example
could look like:
[user1]
flickr-key=ABC
public-by-default=true
[user2]
flickr-key=XYZ
public-by-default=false
Also, adding one extra indirection level if things get more complex
than that is possible: it is possible to use more than one file, e.g:
~/.config/frogr/accounts -- For storing account-dependant things
~/.config/frogr/config -- For general settings
Or even:
~/.config/frogr/accounts/user1
~/.config/frogr/accounts/user2
~/.config/frogr/config
Well, this has the some extra work to use multiple files instead of
only one big XML
> But perhaps I'm just thinking to far in the horizon and it does not make
> sense at all going ahead with the xml file and the GKeyFile idea would
> be just perfect.
Although I am not a big fan of XML (it is far from human-readable,
IMHO), but I understand that XML provides an infinite-nestable
tree-like structure, and that gives a lot of flexibility. I would be
happy keeping the XML as readable as possible by defining a reasonable
schema (e.g. without <super-trooper-extra-long-tags/>).
> > What do you think? Which solution fits Frogr the better?
>
> I think (1) is the way to go, just some doubts choosing the GKeyFile or
> and xml file for that, so woud love to hear your opinion on this.
Summarizing:
1. If we are sure that it will be enough to use GKeyFile, I would go on
using it.
2. If we are not sure whether GKeyFile will be enough in the future, I
would start using a simple XML file right now, whose schema can be
augmented as time passes.
As always, this is only my opinion :P
> Btw, do not worry about the libxml dependency: it's already in the code
> because of libflickcurl, so no extra dependency would be added.
Yep :P
Mario Sanchez Prada
> Ok, I will try to have working code anytime soon for saving account
> authentication tokens and settings for the details window (default
> license, visibility and the like)
Nice. I would bet for doing it so in two steps:
- First: store account-related information not to annoy the user with
the authorization of the app every time it runs, that is, username, frob
and auth tokens. This info should be managed automatically by the
application (no user interaction but pressing the "Authorize" button)
- Second: store other app-related information, as default values for
licensing, visibility, public/private... This will be managed from the
future "settings" or "preferences" dialog.
>> And here it comes up a nice point of mini-discussion... what do you
>> think about using an xml file instead a GKeyFile to store configuration?
>>
>> I understand at this point, when we could be interested only in just
>> saving some very simple data [...] perhaps an XML file could give us extra
>> potential to store more information (e.g. think of adding multi-user
>> support to the app [...]
>
> What about using a section per user profile? For the record, en example
> could look like:
>
> [user1]
> flickr-key=ABC
> public-by-default=true
>
> [user2]
> flickr-key=XYZ
> public-by-default=false
>
> Also, adding one extra indirection level if things get more complex
> than that is possible: it is possible to use more than one file, e.g:
>
> ~/.config/frogr/accounts -- For storing account-dependant things
> ~/.config/frogr/config -- For general settings
>
> Or even:
>
> ~/.config/frogr/accounts/user1
> ~/.config/frogr/accounts/user2
> ~/.config/frogr/config
>
> Well, this has the some extra work to use multiple files instead of
> only one big XML
Yep, that's what I tried to avoid with an xml file, as using XML files
would be valid (and at the same time extensible) to store all the
information that we could need now and in the future.
Btw, I'd use a ~/.frogr directory for all the needed files by frogr,
which I guess they should be just two files, at maximum, right now:
~/.frogr/accounts.xml
~/.frogr/config.xml
Or perhaps just one ~/.frogr/config.xml with everything (app-related and
account-related settings) would be enough at this moment. Guess defining
some simple schema first could help to do the right choice
Does it makes any sense to you?
>> But perhaps I'm just thinking to far in the horizon and it does not make
>> sense at all going ahead with the xml file and the GKeyFile idea would
>> be just perfect.
>
> Although I am not a big fan of XML (it is far from human-readable,
> IMHO), but I understand that XML provides an infinite-nestable
> tree-like structure, and that gives a lot of flexibility. I would be
> happy keeping the XML as readable as possible by defining a reasonable
> schema (e.g. without <super-trooper-extra-long-tags/>).
Yep, please try to avoid too long names, I agree with you that's a nasty
practice ;-)
> Summarizing:
>
> 1. If we are sure that it will be enough to use GKeyFile, I would go on
> using it.
>
> 2. If we are not sure whether GKeyFile will be enough in the future, I
> would start using a simple XML file right now, whose schema can be
> augmented as time passes.
If you do not see a big problem on this, I would bet for this, but hey..
I do not want to look like kind of a boss here... If you think there are
better reasons to do it otherwise just speak up :-)
> As always, this is only my opinion :P
Not "only" your opinion... your opinion is as valuable as anyone else's
and the point of any discussion is just to reach the best consensus as
possible, so do not understimate yourself ;-)
Thanks,
Mario
Adrian Perez de Castro
> Yep, that's what I tried to avoid with an xml file, as using XML files
> would be valid (and at the same time extensible) to store all the
> information that we could need now and in the future.
Okay, going on with (simple!) XML files then :)
> Btw, I'd use a ~/.frogr directory for all the needed files by frogr,
> which I guess they should be just two files, at maximum, right now:
>
> ~/.frogr/accounts.xml
> ~/.frogr/config.xml
I believe it would be nicer to use a ~/.config/frogr, as per the Free
Desktop file system spec I mentioned earlier... most applications are
moving their stuff to ~/.config, as far as I know.
> Or perhaps just one ~/.frogr/config.xml with everything (app-related and
> account-related settings) would be enough at this moment. Guess defining
> some simple schema first could help to do the right choice
I think user accounts have enough entity to have their own config file,
so I would go for:
* Use a global config file: ~/.config/frogr/config.xml
* Use a file per user account: ~/.config/frogr/accounts/*.xml
This would allow for having a direct mapping between GObjects and
configuration files:
* Have a global singleton of FrogrConfig, which backs its data to the
global configuration file.
* Have instances of FrogrConfigAccount, which back their data to
each of the user account configuration files.
I was taking a look at the GObject documentation, and I think it would
be nice to implement configuration settings as object properties. This
way we could directly connect the UI with the config objects, so when a
parameter changes in the UI, the properties will be updated in the
config objects automagically. Also, we get notification signals when
values change for free :)
Also, I read some bits about libxml (tutorials, mostly), and I think
each config object can have its associated xmlDoc* as an attribute.
When a property is set, the XML tree would be modified in-place, so
loading and saving the files is just a pair of calls to libxml
functions (xmlParseFile / xmlSaveFile).
...or maybe the above sounds as overkill?
Next, I would like to brainstorm about which settings would be saved.
As a quick thought, the following comes to my mind (probably I am
missing a lot, that's why I am sharing the list):
FrogrConfig:
* main_window_size: Size of the main window.
Example “config.xml”:
<frogr>
<window name="main">
<width>800</width>
<height>500</height>
</window>>
</frogr>
FrogrConfigAccount:
* name: descriptive account name.
* enabled: Whether the account is enabled. If not enabled, would only
appear in some “account settings” window, but not in the rest of
the UI.
* last_dir: Last directory used in the “add photos” file chooser.
* frob: Flickr authentication frob. (Well, I am not sure if the thing
which needs to be saved is this or the big token -- I have not read
the Flickr API docs yet)
* sharing: Whether photos are public or private by default. Should
remember last-used setting.
- private_family: Whether the “Family” checkbox is enabled when
sharing==private
- private_friends: Whether the “Friends” checkbox is enabled when
sharing==private
* tags: List of tags which are added by default in the photo
properties.
Example “accounts/joe.xml”
<frogr-account>
<description>This is Joe's account</description>
<enabled>true</enabled>
<last-dir>"/home/joe/photos"</last-dir>
<frob>abc-def-ghi</frob>
<sharing>
<public>false</public>
<family>true</family>
<friends>false</friends>
</sharing>
<tags>joe rules</tags>
</frogr-account>
(wow, this was a bit lengthy for an email... :P)
What do you think about this proposal?
P.S. I already made the boilerplate code needed for the FrogrConfig and
FrogrAccountConfig classes, and had to learn to do so because I never
made my own GObject-fu in C before (I used Gtk mostly in Python).
Mario Sanchez Prada
> [...]
Great!
>> Btw, I'd use a ~/.frogr directory for all the needed files by frogr,
>> which I guess they should be just two files, at maximum, right now:
>>
>> ~/.frogr/accounts.xml
>> ~/.frogr/config.xml
>
> I believe it would be nicer to use a ~/.config/frogr, as per the Free
> Desktop file system spec I mentioned earlier... most applications are
> moving their stuff to ~/.config, as far as I know.
Makes sense. Do it that way then (I'm not as much uptodate with fdesktop
as I'd like to, sorry).
>> Or perhaps just one ~/.frogr/config.xml with everything (app-related and
>> account-related settings) would be enough at this moment. Guess defining
>> some simple schema first could help to do the right choice
>
> I think user accounts have enough entity to have their own config file,
> so I would go for:
>
> * Use a global config file: ~/.config/frogr/config.xml
> * Use a file per user account: ~/.config/frogr/accounts/*.xml
>
> This would allow for having a direct mapping between GObjects and
> configuration files:
>
> * Have a global singleton of FrogrConfig, which backs its data to the
> global configuration file.
>
> * Have instances of FrogrConfigAccount, which back their data to
> each of the user account configuration files.
Yep, looks good.
> I was taking a look at the GObject documentation, and I think it would
> be nice to implement configuration settings as object properties. This
> way we could directly connect the UI with the config objects, so when a
> parameter changes in the UI, the properties will be updated in the
> config objects automagically. Also, we get notification signals when
> values change for free :)
Sounds good, but if you think that could take too long I wouldn't oppose
either for a more simple initial solution which worked fine for basic
settings and accounts information, and later on we could always iterate
over it. Saying this because I would like not to wait too long until
releasing the first and shiny 0.1 version :-)
Nevertheless, if you don't see any problem in starting doing it that way
right now, feel free to do it of course. Your idea looks very promising
actually!
> Also, I read some bits about libxml (tutorials, mostly), and I think
> each config object can have its associated xmlDoc* as an attribute.
> When a property is set, the XML tree would be modified in-place, so
> loading and saving the files is just a pair of calls to libxml
> functions (xmlParseFile / xmlSaveFile).
>
> ...or maybe the above sounds as overkill?
The above sounds ok, but this reminds me of a concern I have with memory
usage on this kind of things... perhaps there's not problem at all
(unsignificant amount of data, after all), but one future plan I don't
discard is releasing a version of frogr for handheld devices, such as
maemo devices for instance, just keeping the non UI part of the app and
reimplementing or modifying the UI to fit in those kind of devices.
So, I'd like to keep an eye always on memory consumption when making
design decisions, because if finally porting it to other devices with
not so much assets as a regular PC it would be good to have more a light
design than a perhaps overengineered one.
Just some general concerns, not necessarily a problem on here though.
> Next, I would like to brainstorm about which settings would be saved.
> As a quick thought, the following comes to my mind (probably I am
> missing a lot, that's why I am sharing the list):
>
> FrogrConfig:
>
> * main_window_size: Size of the main window.
>
> Example �config.xml�:
>
> <frogr>
> <window name="main">
> <width>800</width>
> <height>500</height>
> </window>>
> </frogr>
Not sure if this is actually needed. Do you think so? If the purpose is
just to have something to store in the config.xml file, then I would
leave the config.xml out of the game at this moment, and would just add
it in the future, when needed.
> FrogrConfigAccount:
>
> * name: descriptive account name.
If you mean 'username' or 'login id' on here, I agree. For instance,
'mariosp' in my case.
> * enabled: Whether the account is enabled. If not enabled, would only
> appear in some �account settings� window, but not in the rest of
> the UI.
I would leave this out at this moment, while the application does not
have multi-user/multi-account support (which IMHO should be a feature to
be added later on, not for 0.1).
We could add it later on, so good point.
> * last_dir: Last directory used in the �add photos� file chooser.
Not sure about this one. I do not see the problem of always opening in
the same folder, e.g, homedir. Moreover, if you think of the user most
of the times dragging and dropping pictures directly to the GtkIconView
(well, as soon as we have drag&drop) then I guess you'll agree with me
> * frob: Flickr authentication frob. (Well, I am not sure if the thing
> which needs to be saved is this or the big token -- I have not read
> the Flickr API docs yet)
It would be nice to save *both* the *frob* and the *auth token* values.
> * sharing: Whether photos are public or private by default. Should
> remember last-used setting.
> - private_family: Whether the �Family� checkbox is enabled when
> sharing==private
> - private_friends: Whether the �Friends� checkbox is enabled when
> sharing==private
I would have a 'private' setting which could be "true" or "false", for
instance, with two optional nested attributes, 'family' and 'friend',
inside of it.
> * tags: List of tags which are added by default in the photo
> properties.
I'd leave this one out. Does not sounds like a first need for release
0.1, and I'm not even sure it belongs to a common use case for a regular
user.
At this point I have to say that perhaps more info that I do not
remember right now could be needed to be stored, such as the user ID
(not the login name, a flickr generated string) which gets used
sometimes through the API.
> (wow, this was a bit lengthy for an email... :P)
>
You'd better dare not me :-)
> What do you think about this proposal?
>
I think it's quite good actually :-)
So, I guess the best thing right now you should focus on would be to get
a *simple-but-flexible configuration management system*, which would
allow us to easily add more information, if needed in the future. And
for developing it, yes, I would use the proposal discussed above of
fields and structure to start with something. Later on we'll better see
if that's actually enough or not :-)
And of course, keep in mind the 0.1 release will not need many fancy
features (like multiuser support) so, although it's always good to keep
an eye on the future when designing things, do not get too much trouble
with not essential things at this point. Good thing of XML is that
adding those things in the future should not be (hopefully) too hard.
> P.S. I already made the boilerplate code needed for the FrogrConfig and
> FrogrAccountConfig classes, and had to learn to do so because I never
> made my own GObject-fu in C before (I used Gtk mostly in Python).
That sounds perfect. No worrying needed about the GOBject stuff. I guess
you'll start loving C eventually ;-)
So, I've nothing else to say right now... just tell you that I'll be
eager for seeing your awesome patches in this list when you're done.
I'll keep working on other tasks in the meanwhile (just finished the
details dialog task yesterday).
Thanks,
Mario
Mario Sanchez Prada
Mario Sanchez Prada wrote:
> [...]
>> I think user accounts have enough entity to have their own config file,
>> so I would go for:
>>
>> * Use a global config file: ~/.config/frogr/config.xml
>> * Use a file per user account: ~/.config/frogr/accounts/*.xml
I'd rather prefer not to have subdirectories inside .config/frogr (such
as 'accounts') if possible. What about just having the following layout?
* Use a global config file: ~/.config/frogr/config.xml
* Use a file per user account: ~/.config/frogr/accounts.xml
The 'accounts.xml' file would contain all the information for every
account in the system (and remember, single-user app is the current
target at this early stage), this way:
<accounts>
<account>
... data for the first account ...
</account>
<account>
... data for the second account ...
</account>
[...]
<account>
... data for the last account ...
</account>
</accounts>
What do you think?
Thanks,
Mario
Adrian Perez de Castro
>
> Forgot to comment one more issue in previous mail...
>
> Mario Sanchez Prada wrote:
> > [...]
> >> I think user accounts have enough entity to have their own config file,
> >> so I would go for:
> >>
> >> * Use a global config file: ~/.config/frogr/config.xml
> >> * Use a file per user account: ~/.config/frogr/accounts/*.xml
>
> I'd rather prefer not to have subdirectories inside .config/frogr [...]
>
> [snip]
>
> What do you think?
It is okay for me as well.
Adrian Perez de Castro
> Sounds good, but if you think that could take too long I wouldn't oppose
> either for a more simple initial solution which worked fine for basic
> settings and accounts information, and later on we could always iterate
> over it. Saying this because I would like not to wait too long until
> releasing the first and shiny 0.1 version :-)
Well, declaring properties seems straightforward once you learn how to
declare them, so I think they do not pose a problem, hehe.
> > [...]
> >
> > ...or maybe the above sounds as overkill?
>
> The above sounds ok, but this reminds me of a concern I have with memory
> usage [...] because if finally porting it to other devices with
> not so much assets as a regular PC it would be good to have more a light
> design than a perhaps overengineered one.
Sorry, did not think about memory usage, but it is true that there are
nifty portable gadgets which would benefit from having a port of Frogr.
Then I will drop the idea of keeping the xmlDoc structures in memory,
as they eat some valuable space (I remember about reading in Planet
Gnome that memory usage is one of libxml's weak points, in contrast to
other XML parsers).
> > FrogrConfig:
> >
> > * main_window_size: Size of the main window.
>
> Not sure if this is actually needed. Do you think so? If the purpose is
> just to have something to store in the config.xml file, then I would
> leave the config.xml out of the game at this moment, and would just add
> it in the future, when needed.
The idea was to have something for not having an empty “config.xml” --
leaving it as unused at the moment, until we find something interesting
to put inside.
> > FrogrConfigAccount:
> >
> > * name: descriptive account name.
> If you mean 'username' or 'login id' on here, I agree. For instance,
> 'mariosp' in my case.
> > * enabled: Whether the account is enabled. If not enabled, would only
> > appear in some �account settings� window, but not in the rest of
> > the UI.
> I would leave this out at this moment, while the application does not
> have multi-user/multi-account support (which IMHO should be a feature to
> be added later on, not for 0.1).
>
> We could add it later on, so good point.
Okey, let's leave it out for 0.1 because it would add stuff in the UI;
and keep the idea for the future.
> > * last_dir: Last directory used in the "add photos" file chooser.
> Not sure about this one. I do not see the problem of always opening in
> the same folder, e.g, homedir. Moreover, if you think of the user most
> of the times dragging and dropping pictures directly to the GtkIconView
> (well, as soon as we have drag&drop) then I guess you'll agree with me
I understand this is not a very important setting. If users keep asking
for it can be added afterwards.
> > * frob: Flickr authentication frob. (Well, I am not sure if the thing
> > which needs to be saved is this or the big token -- I have not read
> > the Flickr API docs yet)
> It would be nice to save *both* the *frob* and the *auth token* values.
Okay.
> > * sharing [...]
> I would have a 'private' setting which could be "true" or "false", for
> instance, with two optional nested attributes, 'family' and 'friend',
> inside of it.
Nice idea, that makes the config schema simpler.
> > * tags: List of tags which are added by default in the photo
> > properties.
> I'd leave this one out. Does not sounds like a first need for release
> 0.1, and I'm not even sure it belongs to a common use case for a regular
> user.
Okay, leaving it for a post-0.1 release then.
> At this point I have to say that perhaps more info that I do not
> remember right now could be needed to be stored, such as the user ID
> (not the login name, a flickr generated string) which gets used
> sometimes through the API.
Mmmh, I will add a "userid" field then.
> > P.S. I already made the boilerplate code needed for the FrogrConfig and
> > FrogrAccountConfig classes, and had to learn to do so because I never
> > made my own GObject-fu in C before (I used Gtk mostly in Python).
>
> That sounds perfect. No worrying needed about the GOBject stuff. I guess
> you'll start loving C eventually ;-)
I always loved C by itself, but as I have never done serious work with
GLib/GObject/Gtk/Gnome in C some of the things are new for me. It was
"my first love" regarding programming languages, so I have always a
good mood for working with it.
Thanks for all the comments. I will try to have something useable
during the weekend.
Regards,
Mario Sanchez Prada
> [...]
>>>
>>> * main_window_size: Size of the main window.
>> Not sure if this is actually needed. Do you think so? If the purpose is
>> just to have something to store in the config.xml file, then I would
>> leave the config.xml out of the game at this moment, and would just add
>> it in the future, when needed.
>
> leaving it as unused at the moment, until we find something interesting
> to put inside.
So it is what I guessed :-). I'd bet for just using the accounts.xml
file only then at this moment, which is obvious is needed. Do not use a
config.xml file and just keep it in mind, if so, when writting
FrogrConfig so using it in the future would not become a pain in the ass.
> Mmmh, I will add a "userid" field then.
I would not add it yet as it's not needed at this moment for the
current, very small, subset of the whole API we're using, therefore
won't be needed for 0.1. We just need the username, frob and auth token.
Just mentioned it to illustrate why I guess we need a flexible config
system to add things *in the future*, so the user id was an example, not
a request :-) (I do not even recall the exact name of that parameter).
>>> P.S. I already made the boilerplate code needed for the FrogrConfig and
>>> FrogrAccountConfig classes, and had to learn to do so because I never
>>> made my own GObject-fu in C before (I used Gtk mostly in Python).
>> That sounds perfect. No worrying needed about the GOBject stuff. I guess
>> you'll start loving C eventually ;-)
>
> I always loved C by itself, but as I have never done serious work with
> GLib/GObject/Gtk/Gnome in C some of the things are new for me. It was
> "my first love" regarding programming languages, so I have always a
> good mood for working with it.
It's great, do not hesitate about it :-)
> Thanks for all the comments. I will try to have something useable
> during the weekend.
Nice!
Happy hacking!
Mario