I just gave a little contribution against software patents in Europe by signing a petition at stopsoftwarepatents.eu and placing a banner at equinox-project.org page.
Go and vote for patent-free Europe!
Wednesday, January 21, 2009
Tuesday, January 20, 2009
Config class locale fix
After a bit of talk with Double 12, I finaly figured out why Config class (including Resource too) in edelib, could not fetch float values correctly in different locales, although it writes them fine. Nothing fancy but definitely annoying. Fixed.
Thursday, January 15, 2009
ede-look.org
Did you know for existance of the ede-look.org site? Neither did I :)
Yesterday I stumble on it, not sure how and I got myself pretty amazed with it. Now, the only thing left is to fill it :)
Thank you openDesktop.org guys!
Yesterday I stumble on it, not sure how and I got myself pretty amazed with it. Now, the only thing left is to fill it :)
Thank you openDesktop.org guys!
Wednesday, January 14, 2009
No more builtin paths
At last, ede2 module is directed by autoconf from now on. I just completed configure.in file (including all prerequisites for that) so typical edelib "./autogen.sh && jam && jam install" recepie will do the magic.
Some docs are updated too, precisely README.alpha so interested parties can read something useful on how to compile the current code. And yes, it is included as part of manual building process and you will get "Readme First" at the start page.
Only thing that itches me currently are some m4 scripts duplication between edelib and ede. For example, ede2 now uses jam.m4, libxpm.m4 and xlib.m4 scripts from edelib and would be nice if they could be shared somehow. Since edelib and ede2 are separate modules, the only solution I'm seeing now is creating an another (e.g. m4-macros) module. Now, the only "glitch" is that you will have to download it separately and put in ede2 and edelib directories; hm... reminds me to the GNOME way. After a few seconds of thinking, better to keep them duplicate :P
Some docs are updated too, precisely README.alpha so interested parties can read something useful on how to compile the current code. And yes, it is included as part of manual building process and you will get "Readme First" at the start page.
Only thing that itches me currently are some m4 scripts duplication between edelib and ede. For example, ede2 now uses jam.m4, libxpm.m4 and xlib.m4 scripts from edelib and would be nice if they could be shared somehow. Since edelib and ede2 are separate modules, the only solution I'm seeing now is creating an another (e.g. m4-macros) module. Now, the only "glitch" is that you will have to download it separately and put in ede2 and edelib directories; hm... reminds me to the GNOME way. After a few seconds of thinking, better to keep them duplicate :P
Tuesday, January 13, 2009
ede-screensaver-conf refresh
I always asked myself why do we have too many screensaver tools, all of them doing the same thing, like xscreensaver, kscreensaver, gnome-screensaver or xlock; why we don't have one, a good one and numerous frontends for it. Wouldn't be so much simple?
I'm not sure who came first after xlock, but reading a few answers on XScreenSaver FAQ, situation between them (a.k.a. cooperation) is not very good. I don't know how gnome-screensaver works, but kscreensaver (at least one from 3.5.x series) is a wrapper around xscreensaver with own ways of doing things, which makes XScreenSaver author pretty unsatisfying.
After reading those answers on FAQ, you would, as any reasonable person in FOSS worls, starting to ask why those damn KDE/GNOME guys didn't use what already was given to them? Why do they have to invent the wheel all over again filling our hard drives with programs doing same stuff just with different names?
But, it turns out XScreenSaver is not perfect and seems author does not care about it (actually, there is no such a thing as perfection in software, but everyone strives to it). I'm talking here about perfection towards developers, those who want to utilize XScreenSaver with own frontends and addons.
Documentation about this is, simply said, a zero. XScreenSaver is split between daemon and GUI frontend, and the way how they communicate is buried deep in the code, so if you want to discover it, well... go for it. Everything from seeing is daemon is started, sending preview hacks (these are those stuff you are seeing on the screen after screensaver is invoked) and on demand blanking, quitting and etc. is up to you to figure out.
Maybe author didn't want to expose own "messaging API", but many programs can benefit from it. For example, media players can temporarily halt daemon when is started or when those visual effects are played within the song. Yes, some of them (at least I know about Mplayer and Xine) detect it and do the right thing, but how about something more than that?
Let say you want to tell daemon to use specific hack as default one, store own preferences and similar. Yes, these are tasks for own fronted and XScreenSaver is not very fronted friendly. So, what is the solution? Doing the same thing XScreenSaver does; again reinventing the wheel.
During last few days, I was working on ede-screensaver-conf, an improved fronted we had before. I tried to go beyond a major limitation it had before: detecting a new hacks or to be xscreensaver version agnostic.
To be precise, previous version (older name was esvrconf) had builtin list of hacks, copied from one of the older xscreensaver versions and... you know how what happens: thins are changed, options are added/removed and would be nice if ede-screensaver-conf could addopt to these. Also, one of the goals was to read/write directly in ~/.xscreensaver file (where options are stored) so, besides daemon, xscreensaver own GUI fronted could cooperate nicely.
So, did I manage to achive given? Most of it. ede-screensaver-conf will happily read user .xscreensaver file and display needed stuf. If that file does not exists, it will scan for hacks and their config files in usual places and re-generate it. Of course, it will contain only options it needs; for more options you'll still have to run xscreensaver-demo.
One option I'm not going to implement, at least now, is "refreshing for a new hacks" (didn't have a better name). For example, if you add a new hack (in usual hack directory) and user .xscreensaver exists without it, it will not be seen. To see it, you'll have to remove that .xscreensaver file and let ede-screensaver-conf do the rest. Not so complicated :P
And one of the properties I'm very happy about is merging with existing user config file: e.g. you have config file generated with xscreensaver-demo (and filled with all needed and uneeded stuff) and after you change something with ede-screensaver-conf, only changed options will be updated, preserving those written by xscreensaver-demo. At the end, everybody should be happy :)
Now, the only issue left is to finalize GUI look (and test for hidden bugs). Currently it looks like improved esvrconf, but there is a few places for more enhacements. We will see...
I'm not sure who came first after xlock, but reading a few answers on XScreenSaver FAQ, situation between them (a.k.a. cooperation) is not very good. I don't know how gnome-screensaver works, but kscreensaver (at least one from 3.5.x series) is a wrapper around xscreensaver with own ways of doing things, which makes XScreenSaver author pretty unsatisfying.
After reading those answers on FAQ, you would, as any reasonable person in FOSS worls, starting to ask why those damn KDE/GNOME guys didn't use what already was given to them? Why do they have to invent the wheel all over again filling our hard drives with programs doing same stuff just with different names?
But, it turns out XScreenSaver is not perfect and seems author does not care about it (actually, there is no such a thing as perfection in software, but everyone strives to it). I'm talking here about perfection towards developers, those who want to utilize XScreenSaver with own frontends and addons.
Documentation about this is, simply said, a zero. XScreenSaver is split between daemon and GUI frontend, and the way how they communicate is buried deep in the code, so if you want to discover it, well... go for it. Everything from seeing is daemon is started, sending preview hacks (these are those stuff you are seeing on the screen after screensaver is invoked) and on demand blanking, quitting and etc. is up to you to figure out.
Maybe author didn't want to expose own "messaging API", but many programs can benefit from it. For example, media players can temporarily halt daemon when is started or when those visual effects are played within the song. Yes, some of them (at least I know about Mplayer and Xine) detect it and do the right thing, but how about something more than that?
Let say you want to tell daemon to use specific hack as default one, store own preferences and similar. Yes, these are tasks for own fronted and XScreenSaver is not very fronted friendly. So, what is the solution? Doing the same thing XScreenSaver does; again reinventing the wheel.
During last few days, I was working on ede-screensaver-conf, an improved fronted we had before. I tried to go beyond a major limitation it had before: detecting a new hacks or to be xscreensaver version agnostic.
To be precise, previous version (older name was esvrconf) had builtin list of hacks, copied from one of the older xscreensaver versions and... you know how what happens: thins are changed, options are added/removed and would be nice if ede-screensaver-conf could addopt to these. Also, one of the goals was to read/write directly in ~/.xscreensaver file (where options are stored) so, besides daemon, xscreensaver own GUI fronted could cooperate nicely.
So, did I manage to achive given? Most of it. ede-screensaver-conf will happily read user .xscreensaver file and display needed stuf. If that file does not exists, it will scan for hacks and their config files in usual places and re-generate it. Of course, it will contain only options it needs; for more options you'll still have to run xscreensaver-demo.
One option I'm not going to implement, at least now, is "refreshing for a new hacks" (didn't have a better name). For example, if you add a new hack (in usual hack directory) and user .xscreensaver exists without it, it will not be seen. To see it, you'll have to remove that .xscreensaver file and let ede-screensaver-conf do the rest. Not so complicated :P
And one of the properties I'm very happy about is merging with existing user config file: e.g. you have config file generated with xscreensaver-demo (and filled with all needed and uneeded stuff) and after you change something with ede-screensaver-conf, only changed options will be updated, preserving those written by xscreensaver-demo. At the end, everybody should be happy :)
Now, the only issue left is to finalize GUI look (and test for hidden bugs). Currently it looks like improved esvrconf, but there is a few places for more enhacements. We will see...
Subscribe to:
Posts (Atom)