Hello Vincent,<br>
<br>
Sorry that I took so long to reply to this message (properly). Here are a few notes so far about splashy-config:<br>
<br>
* it rocks! the code is very well written and very clear to read<br>
* 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: <br>
splashy/splashy-config/src <br>
splashy/src<br>
and have the #include for xml_parser be done like: ../../src/xml_parser.h<br>
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).<br>
- keep in mind that if we do merge the code in a single src, then
main.c would be renamed to splashy-config_main.c or something like that<br>
* 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 (<a href="http://Polidori.sf.net">Polidori.sf.net</a> is a good
example), so I'll set it up and create a basic .pot file for translators<br>
* 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:<br>
<br>
Something like this (yep, it's buggy):<br>
char* foo = (char*)malloc(strlen("foo")+strlen("/bar"));<br>
strcpy(foo,"foo");<br>
strcat(foo,"/bar");<br>
printf("%s\n",foo); // if it doesn't crash, prints foo/bar<br>
free(foo);<br>
<br>
can be written like (yep, much cleaner):<br>
GString* foo = g_string_new("foo");<br>
g_string_append(foo,"/bar");<br>gprint("%s\n",foo->str); // prints: foo/bar<br>
g_string_free(foo,TRUE);<br>
<br>
* 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)<br>
* 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.<br>
* 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:<br>
splashy-config --create-theme --boot-background background.jpg
--shutdown-background shutdown.jpg --error-background error.jpg
--show-progressbar yes ... <br>
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.<br>
* 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<br>
* loved the xml_format.h file. i think is genius (i've never use scanf() functions. not sure how glib handles that)<br>
* loved xml_functions.c/h files. perfect!<br>
* 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)<br>
<br>
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).<br>
<br>
Keep up the good work!<br>
<br>
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.<br>
<br><div><span class="gmail_quote">On 9/11/05, <b class="gmail_sendername">Vincent Amouret</b> <<a href="mailto:vincent.amouret@gmail.com">vincent.amouret@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello Luis<br>
<br>
I began a backend to splashy-config<br>
I uploaded a test release here: <a href="http://k0fman.t35.com/splashy-config/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://k0fman.t35.com/splashy-config/</a><br>
with some explications.<br>
<br>
There is certainly some bugs but you can see how that work <br>
Say me if I am in the good way if not show it to me<br>
<br>
I use the xml_parser of Splashy which use the glib<br>
so maybe when splashy-config will work fine, i'll re-write it using the glib, too.<br>
<br>
If you have any ideas about options to implement say it, too.<br>
<br>
bye<br clear="all"><br>-- <br><span class="sg">- Vincent Amouret -
</span></blockquote></div><br><br clear="all"><br>-- <br>----)(----- <br>Luis M<br>System Administrator<br><a href="http://Kiskeyix.org">Kiskeyix.org</a> <br><br>"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<br><br>No .doc: <a href="http://www.fsf.org/philosophy/no-word-attachments.es.html">http://www.fsf.org/philosophy/no-word-attachments.es.html</a>