[Splashy-devel] Re: A Splashy Configuration Tool

[Luis M]

Hello Vincent,

Sorry that I took so long to reply to this message (properly). Here are a 
few notes so far about splashy-config:

* it rocks! the code is very well written and very clear to read
* i would like to see it integrated with splashy source code, but i'm not 
too sure about whether it should be kept on its own directory or if it 
should simply be put in the "src" directory of splashy and let 
automake/autotools work their magic about Makefiles (targets and what not). 
Maybe we can simply copy this as: 
splashy/splashy-config/src 
splashy/src
and have the #include for xml_parser be done like: ../../src/xml_parser.h
Since that's the only header that you really need to share. What does 
everybody else think? That would solve the problem of whether they should be 
both in the same src dir and make packaging/releasing easier for all 
distributions (especially Debian).
- keep in mind that if we do merge the code in a single src, then
main.cwould be renamed to splashy-config_main.c or something like that
* I like that a po directory was there. We should use the same idea for 
splashy so that we can have it translated to other languages. I have already 
done this for other projects (Polidori.sf.net <http://Polidori.sf.net> is a 
good example), so I'll set it up and create a basic .pot file for 
translators
* whenever possible, we should replace all str*(), access(), malloc(), and 
all those ugly stlib.h functions with their modern cousins in glib.h. It 
will make things easier in the long run. And besides, there is a long 
history of those functions having security issues. glib.h GStrings is the 
way to go since it simplify things greatly:

Something like this (yep, it's buggy):
char* foo = (char*)malloc(strlen("foo")+strlen("/bar"));
strcpy(foo,"foo");
strcat(foo,"/bar");
printf("%s\n",foo); // if it doesn't crash, prints foo/bar
free(foo);

can be written like (yep, much cleaner):
GString* foo = g_string_new("foo");
g_string_append(foo,"/bar");
gprint("%s\n",foo->str); // prints: foo/bar
g_string_free(foo,TRUE);

* a man page should be created (and one for splashy as well. i did a really 
bad one from a .pod file to speed it up)
* i don't have any issues with calling system() unless we can avoid it. not 
sure if there is a nicer way to use tar from some C code that's part of all 
UNICES... ideas? if not, we can safely assume tar is installed in all UNIX 
systems. not a big deal here.
* i noted that there were two ways to create a theme quickly. not sure how 
you would handle that from the command line, but, perhaps something like 
this would be fine for both:
splashy-config --create-theme --boot-background
background.jpg--shutdown-background
shutdown.jpg --error-background error.jpg --show-progressbar yes ... 
And that means using GNU getopt or glib to parse the arguments (and not 
strcmp()) ;-) and i'd rather do it from glib's own functions. though i have 
never actually done this. But, you are a smart kid, you will figure it out.
* i'm not too sure why would anybody run this as non-root, but, you may have 
your reasons. certainly for the GUI we can use the wonders of libgksu since 
Gnome is integrated with it nicely nowadays
* loved the xml_format.h file. i think is genius (i've never use scanf() 
functions. not sure how glib handles that)
* loved xml_functions.c/h files. perfect!
* we should probably share the common_macros.h files since they don't change 
much and the stuff there is really useful. again, it goes to the same 
argument about using #include "../../src/foo.h" or if the two sources should 
be merged in a single dir (which can be done, but, dunno if it's the best 
thing to do)

Feel free to respond to this message with your ideas, critiques or what have 
you. Please note that splashy-config can also benefit other projects as 
well, like upower and others that use XML files to configure/create/manage 
their themes (fbsplash, bootsplash, etc...). We could try to keep the tool 
as generic as possible. Though it should be easy for other projects to 
simply fork() the code ;-) or use a system of patches (like Vim).

Keep up the good work!

p.s. now that i think about it, i'm not sure how -static-ally compiled 
binaries deal with translations. so, it might not be wise to translate 
splashy strings into other languages. In any case, splashy should not print 
anything to the console (itself) but only care about the displaying of the 
images and progressbar ... we should discuss this further nonetheless.

On 9/11/05, Vincent Amouret <vincent.amouret at gmail.com> wrote:
> 
> Hello Luis
> 
> I began a backend to splashy-config
> I uploaded a test release here: http://k0fman.t35.com/splashy-config/
> with some explications.
> 
> There is certainly some bugs but you can see how that work 
> Say me if I am in the good way if not show it to me
> 
> I use the xml_parser of Splashy which use the glib
> so maybe when splashy-config will work fine, i'll re-write it using the 
> glib, too.
> 
> If you have any ideas about options to implement say it, too.
> 
> bye
> 
> -- 
> - Vincent Amouret - 




-- 
----)(----- 
Luis M
System Administrator
Kiskeyix.org <http://Kiskeyix.org> 

"We think basically you watch television to turn your brain off, and you 
work on your computer when you want to turn your brain on" -- Steve Jobs in 
an interview for MacWorld Magazine 2004-Feb

No .doc: http://www.fsf.org/philosophy/no-word-attachments.es.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/splashy-devel/attachments/20050914/29c72479/attachment.html