Sanel's Acid Words

No more eFLTK

2011-10-31T13:55:00.000-07:00

In the last month there has been a lot of changes in repository. First of all, maybe the most interesting change is that edewm (window manager) was replaced with pekwm, making EDE now fully eFLTK free! This is the major step we headed to in last few years when decided to abandon eFLTK and fully focus on stable (and more maintable) FLTK 1.x.

I chose pekwm simply because it depends only on C++ compiler and X11 libs. I used it (and still using it) heavily with other EDE parts and it works without any major problems. Also, quite important thing for window manager was to have good window manager specification support, so users can replace them without any hassle.

Thanks to ChristTrekker suggestion I played with FLTK based awflwm, but it is still quite behind EDE needs.

Also, important news is how panel (ede-panel) got system tray support (implementing almost full system tray specification, excluding messaging part). This removed one huge limitation for current EDE usage, as more and more applications (and daemons) store own status in tray. Here is image with some apps running on Fedora 15:

There could be some issues I missed, but this thing is working and I'm using it daily (with skype and pidgin of course :)).

ede-launch got some important addition in form of support for preferred applications. This introduced new tool, called ede-preferred-applications from where user can select preferred web browser or terminal. I'm sure you already seen it in form of exo-preferred-applications from Xfce or similar tool from GNOME.

Basically, with this you will be able to run preselected terminal or browser, or simply leave ede-launch to guess your input and deduce what to run.

ede-launch can now directly run .desktop files too, which will simplify some code in ede-desktop component.

So to summarize, you can do this:

ede-launch http://www.google.com # run selected browser
ede-launch foo@foo.com # run selected mail client
ede-launch --launch terminal ls -la / # list directory in preferred terminal

As ede-launch is used to start almost everything, these features will become quite handy.

What are the major things left to be done before release? There is a small issue with long long support on FreeBSD's Xorg distro (EDE is compiled with -pedantic support yielding error reports when long long is detected, as it is not supported by C++ standard) and iconv inside pekwm (also on FreeBSD) that needs to be resolved. Also, I would like to review translation support and add intltool for easier string extraction from files that are not source code (conf and .desktop files, theme sources and such).

Memory applet and more

2011-10-06T16:09:00.000-07:00

Few days ago I pushed a new applet that will show memory and swap usage.

The shot is above; noting smart behind it, but can be usable especially if you use firefox often or have Fedora/Ubuntu with tons of background processes ;)

edelib got facelifing in debug facility, inspired with debug functions and macros from glib. Previously, debug functions would simply write filename/line/text combination, without knowing from which application is emitted, like:

src/Window.cpp:53: loading 'edeneu' theme

Things become pretty messy when you get a bunch of reports from various place: edelib, ede-desktop, configuraion program(s) and etc. By introducting E_DEBUG_DOMAIN, which is set in compile phase, things looks like this:

[edelib] src/Window.cpp:53: loading 'edeneu' theme
[ede-conf] ede-conf/ede-conf.cpp:105: Can't load config

(of course the last line is pretty descriptive, but things got from edelib aren't obvious)

Also, things related to web hosting are still on hold. I contacted Csoft (as suggested by anonymous in previous post comments), but I'm still waiting for reply. Not sure how can I rely on these guys if I need to wait almost a month for a simple answer...

Web page is down

2011-08-17T13:27:00.000-07:00

equinox-project.org is down; seems like the company that hosted our pages went out of business (Sohlius). Unfortunately all pages, including wiki and bugzilla, are inaccessible.

I tried to speak with LiquidWeb guys, as Sohlius contact is not replying, but without success. Sohlius was serving sites from LiquidWeb servers and this was naturaly next step.

Until someone from Sohlius does not contact them, our data would remain inaccessible. So sad.

I will try to setup some temporary pages until find some better solution, or get some reply from Sohlius crew.

Still Still rollin

2011-03-09T13:06:00.000-08:00

Wow, looking backward, the similar post was almost a year ago. And it was like yesterday :)

Yep, the same working place as year ago, and a bunch of new technologies learned in the mean time. But, I'm still missing that rustiness of C++ and jam-s bug-ability, as I'm now in ruby/java/enterprise land where optimization means nothing and every slow-iness is rewarded with more RAM or disk. Looks like the world is going in different direction.

I'm not sure are you familiar, but EDE in some parts uses TinyScheme. Actually, except some playground, tinyscheme (all lowercase, easier to type) is used to describe schemes/themes, although there are few bits left to be completed. Still not sure about language choice, but believe me, I went through all 'modern' languages and still can't get that warm code-is-data feeling I'm getting from scheme (or any other Lisp).

The reason I'm mentioning tinyscheme is how recently was quietly released 1.40 version. The release have a few my patches, including one new feature hardly found in other scheme implementations: error line report in parsing phase. This becomes quite handy when the source grow over 10 lines ;)

Also, I must mention how I received a wonderful patch from Damon, still pending to add on repo. It gives ability to configure ede-panel, something I never manage to finish. Damon, sorry for taking too long to merge it, but I didn't forget about it. Thank you again!

Mozilla's new language?

2010-08-08T14:35:00.000-07:00

Looks like, these days, is quite popular every company/organization to start own language.

I just noticed on LU how Mozilla is developing own language, called Rust. How does it look like? Well, if you know C and bit of Python, you already know Rust.

Boring...

Ahem...

2010-03-25T15:40:00.000-07:00

Check this excerpt from one (very similar) project description I stumbled upon (project name is replaced with XYZ, but astute reader will easily figure it's name):

... XYZ is designed for cloud networks such as local freifunk clouds or the global Internet cloud. It can be built on top of various Linux distributions such as Ubuntu or Debian. It provides a fast desktop experience connecting easily with applications in the cloud and supports a wealth of programs, that can be installed with Linux systems locally. ...

Looks like I'll have to find some manager to write a few words on EDE wiki :P

Still rollin

2010-03-21T16:13:00.000-07:00

Huh boy, I noticed the last post is old more than a month ago; the time is passing for me recently much faster than usually.

Probably the main reason for this is my new job, and some time I need to get used to new environment, people, workflow and the rest of the package that comes with it. As consequence, I had to shutdown (hopefully only temporarily) build farm, as build computers were hosted in facility owned my previous employee.

Other than that, I finally installed 64-bit Slackware 13, which I planned to do for some time. Maybe the main reason for this was to see how EDE will work on pure 64-bit platform; personally, 32-bit, 64-bit, they are all the same for me, except additional burden to learn assembler for different architecture (it is always good to know some asm when you do gdb beyond dumping simple backtrace).

Unexpectedly (duh!), I found problems in EDE code, both compiling and working. Compiling errors were mostly caused by newer gcc (due stdarg changes in glibc) and (as usually) PIC flag(s) for library creation.

Working errors were caused by some pointer magic (as expected) and my wrong assumption how WM property data is stored as CARD32 type. Other than this, I didn't find other 64bit specific issues, although this statement should be taken with some caution :)

Also, I added application icon support in ede-panel, as shown in the screenshot below.

This was (and still is) a quick hack and will be in some future stored in edelib, so the code can be used, for example, to show application icon in tooltip or pager.

Clock applet got some tiny refreshing with flat box and tooltip showing current date, like:

AFAIK this behavior is copied by others, so why EDE should be exception ;) Joke aside, this is pretty useful thing; for example I often forget current date and do not want to start ede-datetime just to check what day or weekday today is.

Translations and locale #2

2010-02-16T07:47:00.000-08:00

Did you know that there is no generic tool to extract translation strings from non source files (anything else not related to some programming language, like .desktop files)? Neither did I, until I tried to find one.

Yes, I know about Intltool, but it is too much tied to Automake that makes it pretty cumbersome outside of it. In README, there is short how-to about Intltool usage outside autotools, but the solution simply cries for something better.

Now, taking into account how Intltool is mostly used by default from autotool users, I checked what autotool non-users has to say about this problem, primarly focusing on KDE, as they are using CMake.

Yes, they have solution and is not intltool, but after seeing it, intltool seems to me as the best choice I can get. Besides a full python framework dedicated to this problem, they have a help from cron script that nightly (or at some part of day or week) walks over repository merging and updating translations in .desktop files and presumably, documentation and other like files.

100 heads are smarter than one, but why this (their) solution looks to me pretty cumbersome? I mean, why someone couldn't made something that rest of the world can use, no matter are utilized make, cmake, scons or jam? Clearly, translation problem is not simple as it looks like.

The clear example was/is bad state about general translation are tools we had before. Not counting GUI frontends (like KBabel) which are mostly copies in different toolkits, solutions in form of web frontends (or for God sake anything else smarter than just calling xgettext in background) we only had in form of Pootle project, famous for it's slowness and memory usage.

Now you know why I see (and presumably others) Transifex project as gift from gods. Count to that free service they put on transifex.net for your project and we, users and developers, could not be happier.

But Transifex is still frontend... if we are going to find the root of this problem, maybe we should start from gettext tools. Hell, even xgettext (part of gettext chain) has differences between GNU and OpenSolaris version (presumably the same is for other Solaris-es). Sun version of xgettext is so dumb you can't even specify extraction keyword, so you must use 'gettext' instead e.g. '_' tag we are used to.

On other hand, GNU xgettext is no perfect either: it tries to be smart where it should be dumb. GNU xgettext can recognize programming language of source it scans and can extract translation strings in the way is best in that language. But, sometimes you want different things.

Recently I tried to add translation feature to theming engine in edelib, which includes some Scheme code, inspired with translation tags found in GIMP. Basically I wanted it looks like this:

 (display _"This text will be translated")

but GNU people visualized how things should be in more lispy like:

 (display (_ "This text will be translated"))

so there is no way you can force xgettext to see the first example as valid scheme source code without hackery with sed and shell.

Count to that how Intltool (which uses xgettext) does the same job as xgettext (extract strings from source code), but in own specific way, you simply lose any desire to do anything related to translation in your project.

Translations and locale

2010-02-12T04:58:00.000-08:00

Aside from my busyness with daily job (and messing with ede-scriptbus to make something usable from it), there happened some changes in edelib too. Thanks to Thierry, locale bug and some installation issues in edelib are fixed now.

That was also a perfect time to finally do something about translation stuff in edelib and complete build scripts to install translated files.

I also created EDE related page on Transifex; for now online translation is not possible yet as I have to finalize and adapt translation facility in ede module. Facility exists, but I want to keep it in similar manner as in edelib (have po folders instead locale and store translation template in file named as application, instead messages.pot).

Updated build nodes certificates

2010-01-14T06:39:00.000-08:00

I just updated certificates on buildbot nodes, that failed to do anything useful last three days.

Looks like SF guys has idea how updating repository certificates is not important at all, so they expects you understaind it without yelling why you didn't get any kind of dammit notification.

Thank you SF!

X11 Cursor Themes

2009-12-30T07:33:00.000-08:00

On Arch wiki is a really nice tutorial how to setup custom X11 cursor theme. The good thing is how solution is pretty desktop/wm neutral, so it works under EDE as charm.

I found Chameleon theme very nice; you also get three different sizes: large, medium and small. Neat!

Following above wiki tutorial, I would add how using "~/.icons/default/index.theme" is probably the best solution. You don't have to mess with "~/.Xdefaults", nor need to have permissions to play with "/usr/share/icons" folder.

After you populate "~/.icons/default/index.theme", X11 will instantly load selected cursor theme. The only thing I found are often crashes, originating from libXcursor library. This could be either from graphic driver (nVidia of course) or from older X-es I'm currently running (time to upgrade it).

Charting library

2009-12-14T06:45:00.000-08:00

Sometimes you need to draw charts on more pragmatically way than is usually done. Unfortuately, most of the things out there pretty sucks or are in the good way to do so.

For some time I used PyChart, but due it's complexity and really odd api, I dumped it and get back to OpenOffice. Yes, I went back to stone age, from nice comfort of favorite editor to clicking on eat-all-available-memory OpenOffice.

From time to time, I stumble upon some library, but nothing I would be satisfied with. Until I found guile-charting.

Honestly, Guile is not my favorite package and I install it mostly to play with differences on Scheme implementations, but from no on, guile-charting will be probably the main reason why I will keep Guile package installed.

Here is the sample code (also on pastebin):

(use-modules (charting))

(make-bar-chart "Monthly status for Foo project"
'(("January"
   (232 "Download")
   (20 "Upload"))
 ("February"
   (80 "Download")
   (320 "Upload"))
 ("March"
   (130 "Download")
   (150 "Upload"))
 )

 #:write-to-png "usage.png"
 #:chart-height 200
)

and will produce this:

You will also need guile-cairo for guile-charting.

Communicating with desktop #2

2009-12-08T05:22:00.000-08:00

I imported ede-scriptbus on the repo (it is in branches), adding few new stuff: setting XSETTINGS values and explicit XSETTINGS serialization, which was done implicitly when evoke quits. For example, to change current background color of EDE apps, this will be used:

./ede-scriptbus
> (set-xsettings "Fltk/Background" '(R G B A))

where, as you guessed correctly, you are using separated color components. The good thing about (set-xsettings) is how it will figure out parameter type and send correct message to evoke.

Due the nature of XSETTINGS protocol, changes will be instantly applied.

Too bad Gtk+ (as it implements XSETTINGS) does not implement some keys for changing foreground and background colors, so we could apply color changes on Gtk+ apps too.

Communicating with desktop

2009-12-04T08:23:00.000-08:00

One of the major things I like and admire in KDE is DCOP. With DCOP, you can query, change or list desktop parts with a simple command and a few parameters. Or shortly, you can "inspect" your environment.

I'm not proficient with DCOP, nor had a chance to use it more than experimenting with the given examples, but knowing you can control your environment in the few commands is really powerful concept. Or maybe, controlling it via some language, like Apple did with AppleScript, if we are going to be more serious.

Last few days, I was playing with similar concept in EDE. Of course, for the start, it gives some rudimentary options and we will see how it will expand itself in the future.

I named it "ede-scriptbus"; the name left from my previous attempt to write some simple scripting suport for D-Bus things and, as expected, I ended up with different thing :)

ede-scriptbus comes with embedded Scheme language, via TinyScheme. Now, I hear someone is screaming Lua name, but I already had some code written with TinyScheme, plus I can easily hack interpreter if I need to adjust it. Remember, ede-scriptbus is still in prototype phase.

Now, what can be done with it? For now, it is capable to query application specific settings and XSETTINGS registry (yesterday evoke got changed to export XSETTINGS values via D-Bus). Here is sample image:

Basically, you query desired items, much like you do query on some database. I had to make distinction between XSETTINGS and application settings queries because keys have different format, but this can be easilly wrapped, providing unique query interface.

Adding ability to change existing values or set new key/value pairs should not be hard either and this is next in my TODO list. But, there is one issue I'm still contemplating: documentation of configuration values. Huh boy, this sounds scary :)

One of the greates irony of configuration files (meaning about those INI style files desktops are using extensively) is how they are readable and can be easily changed. Yes, you can easily view the content, but how much stuff you can understaind from it?

Here is excerpt of ede-desktop config file:

[Desktop]
color=0
wallpaper_use=1
wallpaper_mode=0
wallpaper=/home/sanelz/walls/diablo3.jpg

You already understaind how "wallpaper" key has full path to background image, but what "color" stands for? Background color? Yes, but what values it can have, or what values should be in "wallpaper_mode" when you want to stretch background image?

This problem is not only EDE related; look my qtrc (Qt configuration file) for example:

[General]
GUIEffects=none
XIMInputStyle=On The Spot
cursorFlashTime=1000
doubleClickInterval=400

The same problem here. GConf has ability to document these things, but GConf is story for itself.

Actually, the idea is that the person who changes the key/values via ede-scriptbus, can query their description too, like:

> (doc "Net/IconThemeName")
"(type string)"
"The name for currently used icon theme. Changing the name to different
icon theme will immediately be applied on all EDE and Gtk+ applications."

Would be neat, but, is it possible to do it?

First things first, I need to complete this tool and we will see the next steps :)

EDE on LWN

2009-11-18T07:54:00.000-08:00

I noticed a short EDE review on lwn.net. Thanks guys!

One up one down

2009-11-16T05:39:00.000-08:00

EDE's modest build farm got a new member and lost old one. The new member is OpenSolaris (2009.06), run under VM, and retired one (at least for now) is FreeBSD.

Due power failure, on machine with FreeBSD installed, network card died and replacing is pretty impossible (old Compaq Proliant I found in some basement).

Some EDE parts are not yet compileable under OpenSolaris and I commited today some changes to get greens from edelib unit tests.

pkg-config on OpenSolaris

2009-11-11T08:47:00.001-08:00

You want pkg-config on OpenSolaris? No problem, just install 4.20 MB gnome-common-devel package. Now, that's reeeeaaaaalllllyyyy smart!

Linux Kongress Summa Summarum

2009-11-10T07:09:00.000-08:00

Altough I get back a week ago, a shoulder issue prevented me to do anything useful here and on the repo. Probably due carrying those bags with laptop. Now I'm definitely starting to prefer some lighter variants :)

Linux Kongress was excelent. Organization, people, everything. I should mention OSDevCon happening in the same time at the same place, but due daily schedule in LK rooms, haven't catch anything from OpenSolaris guys, except a few t-shirts :)

And Dresden... a beautiful city. Definitely should be visited again :)

I finally met Michael "STIBS" Stibane (remember STX distro?); he is, guess, from Dresden. We had a great dinner and talk about almost anything. A great guy!

At the end, a trip worth every penny, pardon, euro :)

Linux Kongress Talk

2009-10-22T04:22:00.000-07:00

I'll give a talk about EDE at Linux Kongress in Dresden, October 30th at 11:00am, so feel free to come if you are near by :)

See you there!

Some new things...

2009-10-16T03:35:00.000-07:00

After beta release I haven't be much lazy, so I completed and merged the two new features: keyboard layout applet and shutdown/restart support via HAL daemon.

Keyboard layout manager we had built in panel in EDE 1.x parsed X key rules and directly called setxkbmap. Changed preferences were stored in EDE known configuration file read at panel startup.

Of course, with this approach the panel was pretty agnostic to outside changes, e.g., you change the layout via setxkbmap tool, the panel will not get it and will happily display the layout used when panel was up. Don't have to say how this could be pretty confusing for the viewer.

New keyboard layout applet resolves this, thanks to XKb extension. Unfortunately this extension (as most of X code) is pretty badly documented, so I had to dig around to figure out how the things work. Now, every keyboard layout changes during X session will be correctly caught no matter what tool was used, while the layout is stored in X server.

Also I added some nifty flags found at kde-look.org link that will match the named layout, completing the final visual appeal.

Unrelated to this, shutdown and restart actions are from now, by default, HAL powered. Just make sure you have enough permissions to do this; for example, on Slackware is pretty easy: just add yourself in power group and you will get them.

If this is not suitable for you, just set desired group for org.freedesktop.Hal.Device.SystemPowerManagement interface in /etc/dbus-1/system.d/hal.conf file.

On systems where HAL is not present, fallback will be done on standard shutdown command.

EDE 2.0 beta released

2009-10-08T08:50:00.000-07:00

Enjoy :)

New panel merged

2009-10-05T06:30:00.000-07:00

New ede-panel is now merged in the trunk. Actually this was done two days ago, but additional management (fixing build paths, install/uninstall scripts and such) had to be done, so everything could work nicely.

What to say about it? ede-panel is written from the scratch and is using FLTK, meaning: one program less using eFLTK. Everything is placed in applets, so only things that will be used will be loaded. This will reduce memory usage and provide the base for future extensions or replacements (e.g. if you do not like current quick-launch applet, write a better one ;)).

Also, noticeable feature is support for fd.o menu specification. Now, all your installed applications will be correctly recognized and populated in desired menu section. Of course, if they are fd.o menu aware and this is the case for almost all modern GUI applications.

Here is the shot of default EDE menu layout:

Initial menu layout was taken from Xfce mostly because it is simple, concise and manageable ...and because I had no inspiration to write another XML file. Of course, the layout will be changed even more depending on requirements in upcoming period.

Moving release date

2009-09-30T04:14:00.000-07:00

I'll have to move release date, planned for September, in October.

As I mentioned in the comment of previous post, the main reason is how Menu Specification took longer to implement than I expected. Now I understaind why LXDE guys decided to not implement it: it is simply too complicated for this simple task.

Yes, it is powerfull, but the things could be simplified a little bit. Hell, you even have a pattern matcher in it!

For example, why do I have to care about legacy menus; they are not used any more and the spec should mention it in initial draft, not carry it through all versions. You implement it once, do the conversion and there are no more needs for legacy menus.

Or merging: couldn't one perl/python script solve this? Even better, both things could be put in one script called when desktop starts.

Current implementation in EDE is not full; menu merging and layout customizing is not yet supported and I will leave them for the future version(s). Those things that are supported are passing official menu regression tests.

Of course, partial implementation will not cripple the final menu presentation if sane menu configuration is used (e.g. like the one shipped with Xfce). Or you are definitely trying to complicate the things :P

Green tests on NetBSD

2009-09-23T06:19:00.000-07:00

For a long time, mime type related tests in edelib were failing on our NetBSD buildbot node. Also, the part of this was known bug where tests would crash when given path was ended with "/" (the same applied for root path).

This issue is fixed now and we have "greens" on all buildbot nodes :)

Wiki update

2009-09-21T01:21:00.000-07:00

The new wiki is on, as planned. All content from older, Trac based wiki, is transfered, plus some new things were added.

Back from vacation

2009-09-04T04:50:00.000-07:00

...unfortunately :) It's hard to get used to on daily job activities, not to say how I had to totaly reorganize my sleeping time.

In EDE-land there are changes too. During this vacation I had a chance to experiment with FLTK (and edelib) theming capabilities, merging that into pretty capable theming engine.

Now, theming engine is a part of edelib; most of it is completed with a few remaining bits. More about it should come soon.

SELinux and FLTK

2009-08-03T16:06:00.000-07:00

I often hear complains from people I know how SELinux gives more problems than it solves it. I never had this problems, simply because I'm not using it nor had a needs to use it (implying how I'm not using distros where it comes).

As I'm currently working on ede-panel and applet loading code (better to say: "still mocking up the things with it") and in the mean time, all that test on Fedora 10.

After everything worked as charm on Slack (my default distro), this wasn't the case with Fedora; as you guess, SELinux is the problem.

When I started ede-panel, I got warning window with this error:

SELinux is preventing ede-panel from loading (...)/eapplet_demo.so which requires text relocation.

Of course, applet wasn't loaded and if this is going to be the case in the future, ede-panel will be pretty unusable because I'm planning to put most of the stuff in applets.

Now, back to SELinux... SELinux offered me the way how to "fix" this with full command line example, but also suggested how this is mostly a bug in the program. Probably it is, but finding text relocations in the code can be very consuming process (that is what people said; I never needed to do this :)).

This is the document explaining what and how, plus mentioning the tool I wasn't aware of: eu-findtextrel". After running it on applet demo, guess: it pointed me on FLTK.

I compile FLTK mostly as static library; don't know why, probably the habit, and when FLTK is compiled as this, -fPIC flag is not used. As above document sais, you have to use it.

So, recompiling FLTK made SELinux happy. This also worries me: FLTK has to be distributed either as shared library (default on Fedora) or it has to use above flag even if compiled as static library (compiling FLTK as static library is default option when FLTK is compiled from source). This is the case only for SELinux enabled distros.

Luckily, FLTK on Fedora already comes as shared library so this is not the problem at all. The only problem is when FLTK is compiled straight from the source code, but at least we have solution, right :)

Better netinstall

2009-07-30T07:54:00.000-07:00

During perod while I was setting up moin and preparing a stuff for the new web pages, I took some time and rewrote NetInstall script (Note: link to netinstall can be changed in the mean time).

Previous netinstall, used to build EDE 1.1 and 1.2 was written in shell. I got inspiration for it from GWARE's install script (or there were another project, can't remember).

Shell version worked as expected; after few tunings even worked on FreeBSD (probably on OpenBSD too), but the drawback was the shell itself. Is already known how shell scripts can easily become unportable, especially if you get used on some very cool "bash-isms".

To make the story shorter, the new version is re-written in python, so using this script should not be a problem, since python comes with every distro and is often installed by default. Originally I wanted to do it in perl (to refresh my knowledge), but the final version emerged from one of the quick mockups I did in python and redoing that again would be a waste of time. I will leave perl for something else.

Shots of shell tools are not fancy, but everyone would like to see them anyway, so here is the one:

So what was done here? Well, netinstall is not static tool any more (read this as: "with stored package data") and contrary to the previous shell version, it can be downloaded and used multiple times.

Package information and details (a.k.a. metadata) are stored in separate files (named config files) and are downloaded from EDE web server. For example, here is how looks like default file. Nothing complicated.

But, the main "pro" of this approach is ability do build different EDE versions (or build EDE in few different ways), with a single tool. For example, by default, netinstall will build EDE 1.2, downloading eFLTK and correct EDE packages.

If you want to play a little bit with 2.0 version, you just type:

./netinstall --config ede-2.0.cfg

and voila; everything needed will be downloaded, compiled, patched if needed and installed. On other hand, if you don't have FLTK already installed, using:

./netinstall --config ede-2.0-full.cfg

will even download FLTK and compile it and install it, besides other EDE packages.

I know how how someone will try to compare it with Jhbuild and ask why I didn't use it first, but Jhbuild is way from netinstall goals. Jhbuild is kitchen sink that can do a lot of things, but you need to install it first, bootstrap it and perform some magic. In the mean time you could already download and manualy compile all EDE dependencies :P

I want netinstall to keep "download-and-run-it" spirit, with as less as possible hassle for user. That is the main goal.

Anyway, documentation needs to be completed and the code needs to be tested a little bit more.

Hooked on Isis

2009-07-29T05:34:00.000-07:00

I really got hooked on Isis and their Oceanic and Panopticon albums. Still didn't listen the rest of their discography until I study these two as much as possible.

Heck, I even installed good ol' xmms because audacious equalizer makes absolutely pathetic sound on anything better than ordinary speakers.

Currently MoinMoin-ing...

2009-07-21T05:30:00.000-07:00

Yep, I'm messing with MoinMoin last few days. I'm planning to replace current EDE web pages with it for easier content management.

Buildbot is running :)

2009-07-09T05:58:00.000-07:00

I set up buildbot on http://build.equinox-project.org. It is scheduled to do nightly builds, downloading and compiling both edelib and ede2 modules, with execution of edelib unittests.

Builds are done on Slack 12.0, FreeBSD 5.3 and NetBSD 4.0.1.

To be honest, I set it up few months ago just to see how it will work and behave. Amazing tool!

Menus with icons

2009-07-03T04:03:00.000-07:00

I just commited the new menu "system" in edelib trunk (actually, it is not really new, but forked FLTK menu code).

FLTK menus are fine, fast and works well. But there are few missing pieces, like custom icons in menu items. Actually, you can set an icon, but menu item label will not be shown, since that icon will be considered as label. Strange decision. Also, setting icons with custom sizes is not possible.

On other hand, extending menu code in FLTK is pretty impossible. One of the most important part of FLTK menus, Fl_Menu_Item, can't be inherited to allow custom item draws, so if do you even the smallest change in this class, you'll have to pull all Fl_Menu_* code and change it to use your Fl_Menu_Item modification. Pretty scary, isn't.

So, you know why it is forked :). Also, this is not the only reason. With this comes greater flexibility in future extending, adding custom drawing effects, improve scheming ability or similar things. Besides, I planned to use them for ede-panel, and these menus has to be little bit "more" than plain FLTK menus.

Here is how it looks like:

I know, nothing fancy and looks like menus in any other toolkit. And that is the point :). Also, icons with different sizes can be used, aligning their labels nicely. It doesn't look pretty and hardly anyone will use icons with non-uniform sizes, but follows FLTK way where each menu item could have different label size, font or color.

Contrary to Qt style (where you always have gap from the left size, no matter was icon used or not in the menu item), I took Gtk approach: if there is no icon, there will be no gap (like it is shown in above submenu). This gives some kind of FLTK "compatible" feeling.

Application code should not be changed considerably either. Instead Fl_Menu_Item or Fl_Menu_Bar, putting edelib::MenuItem or edelib::MenuBar will do the job allowing to use FLUID generated menus without much of the trouble.

New bug report tool

2009-07-01T05:29:00.000-07:00

Last few days I spent working on this tool: a small tool that will make life easier for those who would like to quickly report bugs on our Bugzilla (named ede-bug-report, nothing fancy ;)). Those familiary with bug-buddy from GNOME will know what I'm talking about :)

Anyway, this development was my first expirience with xmlrpc-c library. For those who do not knows, Bugzilla exposes own API via XMLRPC protocol so if you have the right libraries (or enough bravery to write your own), you can nicely access it without using browser (with consulting Bugzilla API documentation, of course).

I can summarize using xmlrpc-c with two words: very painful. I had to rewrite bugzilla client three times, mostly due bad xmlrpc-c documentation. The first time (maybe this shouldn't be counted) was client emerged from my playground with Bugzilla API. This client was synchronous and was pretty unusable with GUI, but was working.

Second try was with xmlrpc-c asynchronous API, and after a few days of guessing how things should work (because documentation is horribly bad in this part), I managed to get it running. At least I though it.

Somehow, xmlrpc-c asynchronous API badly manage cookie sessions so after loggin in, submitting bug wasn't posssible and Bugzilla would report how I'm not logged in. I'm not sure is this due this library or I was doing something wrong (hardly since you have only few async functions and is pretty hard to get things wrong :P) but I couldn't get it running in any way.

And, at the end, the third try was/is synchronous client with threading. Although I'm not a big fan of threading, using threads was very joyable comparing to horrible xmlrpc-c async API. Damnit, you can't even cancel requests with it, so if you try to shut down the client forcefully, you'll get assertion straigth from the library.

Asside from these internal stuff, I tried to keep client's GUI pretty minimal. When I get those bug report dialogs with tons of input fields, I lose desire to report the bug, no matter how critical it was. Few fields and let developers sort it as they like, right :). Here is the shot:

Next is to make it work together with ede-crasher, so when something crashes, users get an option to report it in the same time. And move it from the branches in the trunk, of course.

No EDE on LinuxTag 2009

2009-06-19T08:49:00.000-07:00

Unfortunately :(

I wasn't able to find reliable sponsor and other guys had to cancel due personal issues. Probably this global recession had a large part in this so companies are very reluctant to give money for anything except they have to.

I'm pretty sad for this since I had to cancel two things: our booth and my presentation.

EDE on LinuxTag 2009!

2009-05-13T06:48:00.000-07:00

Although this news is not very fresh (shame on me for not putting it on the time), there is some fresh-er: I will have a keynote at LinuxTag, titled as "EDE as desktop environment alternative" and is scheduled 27.05.2009 at 15:30 in Saal 4.

Now, "the only" remaining thing left is to handle papers and find some sponsors...

How to kill remaining C++ programmers?

2009-05-08T07:00:00.000-07:00

Just show them upcomming C++Ox stuff. After seeing this stuff, I'm sure how Haskell will be very logic and natural to you.

Btw. reddit pointed me to Alexandrescu's talk about iterator alternatives, where he showed some snippets how file should be copied via "modern" C++. Now, if someone tells me how lisp is unreadable... :)

EDE 2.0 alpha released

2009-04-22T09:30:00.000-07:00

Finally... :)

Going from Trac to Bugzilla #2

2009-04-10T08:44:00.000-07:00

...was done. Now I'm going to setup some buildbots.

Going from Trac to Bugzilla

2009-04-04T06:36:00.000-07:00

It is time we go serious, so we should use some serious tools :P.

First of all, why switching to Bugzilla? Trac is a nice tool; you get almost everything you need with one installation, not to say how is easy to set it up. On other hand, Trac is trying to be everything, so you get something from every other tool it copies. The key here is "something".

Honestly, I was afraid of Bugzilla. It's interface makes me cry, it's database layout makes me go nuts, but in the end, it has one important property Trac is missing: damint stabile codebase. Not to say how you can configure almost every possible detail in it.

One thing sucks badly: you can't find usable scripts to do transition. With Trac, you already get bugzilla2trac.py script (if I can remember), but opposite... you can't find it easily.

So, after searching and searching, one day Google was in the good mood and spit out in the first page of search results link on the Will's blog, a nice guy that had the similar problem. The best thing of all was he already wrote a script for own database transition. Excellent! And Will, thank you a lot!

The script is a little bit specific for his Trac database, but with a little python knowledge, few tries and small amount of luck, you can get it working for own case.

Luckily, the number of our bugs is not huge, so running script with the few manual interventions completed the job. Sweet! Now, we even have a nicely separated eFLTK and EDE bugs ;)

Riding EDE on SunStudio

2009-03-30T08:23:00.000-07:00

Note: this is not tutorial about how to compile EDE 1.x on SunStudio compiler, but impressions after compiling ede2 module (EDE 2.0).

As I wrote before, edelib and FLTK works fine with SunStudio 12 compiler. Of course, since I didn't tried edelib on this compiler for some time, some small tweaks were needed; these were mostly setting correct path to the compiler and runtime libraries (and preventing linkage with gcc libraries). Now, these steps are nicely documented in INSTALL files that comes with edelib.

So, after compiling edelib and FLTK (did I say how you must compile FLTK on SunStudio too?), EDE came. Procedure was mostly the same, except I had to hardcode fltk-config path in the configure script.

This was mandatory since configure would pick up system's fltk-config (FLTK compiled with gcc), not the one compiled with SunStudio (I placed this one in /opt/fltk-sun). This got me nice TODO to add --with-fltk-path in configure script, the same flag edelib has for these purposes.

So, before I fired jam, I disabled compiling edewm, ede-panel and efiler. edewm and ede-panel are still on eFLTK and didn't compiled eFLTK with sun's compiler. On other hand, Vedran didn't have time to update efiler on the latest edelib changes, so, generally speaking, efiler is and will be in uncompileable state for some time (I'll have to motivate him to fix this, because I don't like when repo code can't be compiled).

Compiling went fine; few small errors popped up (explicit casting to const char**, nothing serious) and a bunch of warnings, which is good :) Although I tend to compile edelib and ede with -Wall and -pedantic flags, gcc didn't complained so far.

As usually, I got a few Anachronism-istic warnings and a few vairable shadow-ings. The one was pretty interesting and I'm curious how gcc didn't catch it.

MessageBox::set_input() was implemented like this:

void MessageBox::set_input(const char* txt) {
  if(inpt)
      inpt->value(txt);
}

but MessageBox had txt as private member too. Of course, gcc was smart and got my intention, but I would much prefer some warning here. +1 for SunStudio!

Now, to save me from these from-time-to-time-remember-to-compile-with-this-or-that, I'm planning to setup buildbot with the nightly builds. Before some time, I played with CDash (via their public service), where I had to instruct edelib to generate cdash-like test result output.

I don't know what happened; few times I couldn't submit results probably because server went offline and after that, I couldn't even login to edelib CDash account (I just checked now; seems edelib is still there :)).

But, I will try to stick with the buildbot this time. CDash is CMake centric and buildbot does not need special output files to figure out were builds or tests successfull of not. There are more things to say, but since their concepts are pretty different, comparaison wouldn't be fair.

edelib-new-icon-theme merged

2009-03-25T05:13:00.000-07:00

Title speaks for itself :)

Why we needed a new icon loader? Well, because we needed it :P. IconTheme class was way too much monolithic; there you had icon snarfer from the theme, some kind of caching facility to reduce access() and everything that packed in a singleton class. Not bad for some basic usage.

I wanted some things beyond that, mainly to allow dynamic icons reload when the icon theme was changed during desktop session. You know, telling "Please restart your desktop" just because you changed icon theme reminds me on Win 95 days. Don't get me wrong; I'm not fond of the GNOME's instant-apply-on-the-click approach either, but let we leave "Please restart..." way for some serious stuff :)

Also, one thing itched me a lot: checks after icon was fetched. We had before:

String path = IconTheme::get("foo-icon", ...);
if(path.empty()) {
  /* try to get "empty" icon */
  path = IconTheme::get("empty", ...);
  if(path.empty())
     /* bail */
}

Fl_Image* img = Fl_Shared_Image::get(path.c_str());
if(!img)
  /* bail */

/* finally load it */
widget->image(img);

I already lost inspiration to load some icons.

Now, by introducing IconLoader, things are reduced to this:

IconLoader::set(widget, "foo-icon", ...);

Much better.

This introduces a lot of benefits; first it reduces the code, then it will automatically update widget's image when icon theme was changed (for this Window class must be used) and, most important, allow me to explore efficient ways of icon loading (or whatever) without going in each program and update the changes.

Of course, this solution is not perfect. There is no way to track when widget or image was destroyed (except beeing inside FLTK), so, from time to time, it is good to call IconLoader::repoll() to update internal tracker. This thing is only needed when the large number of widgets or icons are loaded or destroyed in the short period.

IconTheme is still there; now is class related to the only one thing: loading icon theme and it's metadata. This allows loading two different themes in the same time (for example, to fetch descriptions, sample icons and etc.).

Someone will notice similarities with KIconTheme and KIconLoader from kdelibs. That is because I had pretty blur idea how it should be done, so I peeked a little bit how expirienced guys did it. Except similar class and method names, everything else is different.

edelib-new-icon-theme branch also introduced some improvements in Window and MimeType classes (like using user defined icons for mime types).

By the way, recently someone send me a link on discussion from Wolvix forum. Thank you!

NetworkManager sux (or not)

2009-03-22T03:19:00.000-07:00

Last night I installed Fedora 10 (actually, I had it on my VirtualBox, but this time I wanted it on the disk), so that was a perfect time to test NetworkManager. I like when they said: "The most important pieces of NetworkManager are desktop-environment and distribution agnostic": gives me some neat ideas :D

Anyway, in my case, I have a wireless card that needed to be connected via xDSL. Nothing complicated, but...

I'm not sure was it fault due NetworkManager or GNOME's fronted, but I couldn't make it to see wireless card in "Hardware Device" tab; strange, since the card was regularly recognized in main hardware section.

So, after some searching (and more searching), I found out how NetworkManager is still a young project, with a plenty of time for improvements :). That send me to the good old terminal and "pppoe-setup".

edelib-new-icon-theme branch

2009-03-16T10:35:00.000-07:00

The new icon theme code is on the road, and there is edelib-new-icon-theme branch (I haven't commited changes yet). This change will break a lot of things, but it is better to do that now, than later.

Reasons for these changes will be, hopefully, typed soon :)

Playing with D-BUS service autostart

2009-03-09T00:59:00.000-07:00

Offtopic: a small undocumented issue in edelib about registering unique D-BUS name was fixed in the repo. I'm not sure how I missed this; probably I was thinking that native dbus_bus_request_name() will do all the work, but it turns out that it is much more powerfull than simply name request. Check out D-BUS docs about it (read that part few times, they complicated a little bit with explaination ;)).

D-BUS service autostart (I'm using word "autostart", but docs are saying "start"; feels much more natural) is one very cool D-BUS feature (probably inspired with CORBA), where D-BUS would start a service provider on demand. E.g. you have org.example.Test service implemented in test-daemon, but you don't want to run in in the background all the time, only when is really needed. As D-BUS specs prescribes, you simply create an .desktop like file, ends it with .service (preferring way is to use service-like name, e.g. org.example.Test.service) and put in D-BUS service directory. Now, when you first time conntact this service, test-daemon would be spawned and apps would happily starts to consume org.example.Test.

So, following this, I added Startup Notification support in ede-launch-sn, a small helper tool for ede-launch command I quickly constructed just for this; ede-launch would connect on org.equinoxproject.StartupNotify and call StartupNotify member, initiating notification sequence. Then ede-launch-sn would terminate that sequence after some timeout.

Startup Notification listener is not implemented yet, so notification is only seen in window managers (or environments) that has support for it.

I didn't put the code on the repo because I still didn't figure out should we need another service in the background and/or how could it be nicely blended in ede-launch command.

slacky.eu

2009-03-05T06:33:00.000-08:00

Totally by accident, searching for Valgrind package for one of my (still not yet up to date) Slackwares 12.0 (yes, I'm lazy to compile it), I stumbled on this site by the Italian Slackware Community.

They have a large package repository (everything you won't find on official CDs/DVD), and guess, there is EDE package too. Awesome!

Go slacky.eu, go :)

Trashing stuff

2009-02-25T09:44:00.000-08:00

Just noticed a trash-cli gets a fresh release.

It could be the solution for uniform EDE trashing things, without re-implementing the same things all over the place. Or, it could be an idea for implementing EDE's own trashing tools... just thoughts :)

Integration, integration

2009-02-20T09:18:00.000-08:00

Just "integrated" (ha, soundy word) edewm (window manager) and eworkpanel (now known simply as ede-panel) in ede2 module. No, they are not new and fancy but an older versions from 1.x code.

Why? Well, you have to have something that will manage your windows and raise them when gots minimized (and in the mean time work that well). The newer window manager currently exists, incompleted, in branches and it's finalizing I'm planning for 2.0 beta or similar (see Roadmap). Completing it would eat up too much of the time, so plans for alpha are to use older panel and window manager and see how everything else fits together (which is IMHO much more important than anything else).

You know, you can have a perfect window manager and even better panel or desktop, but if they are not "compatible" (as people would say), then is bad. Kinda reminds me on relationships :)

So, to sum up the things, everything works as expected. EDE is starting nicely (belive me or not, this is the first time I'm starting full EDE without problems and various hackery behind!). Quitting is not done yet (ede-panel still does not communicate well with evoke) and there are few issues with the menu links.

More to come soon, hopefully ;)

evoke merged

2009-02-19T06:19:00.000-08:00

...in the trunk. Latest addons (with a small refactoring) was an autostart support (actualy, imported from previous version and modified) and switching to the recent edelib changes in Resource class.

evoke documentation partially finished mostly due plans for better reorganization. It would be nice to have clearly documented starting/quitting process, how to create a splash theme and bits related to the XSETTINGS values.

evoke rewrite

2009-02-17T04:41:00.000-08:00

evoke is going to branches for a fresh code. Actually, most of it is already done (just merged), where I kept old xsettings and splash engine code (with a small improvements).

evoke is an EDE "starter" (it will start needed EDE programs) and "quitter" (will gracefully close all running programs and close X connection). It will also run splash at the startup, start programs from autostart folders and keep xsettings session. In short, manage startup and quitting and everything related to this.

Maybe it looks like a kitchen sink, but believe me, before this "code redux" it was a much worse kitchen sink. It had an option to run external programs, monitor it and report if they crashes and managed screen composition (a.k.a. composite manager). Add to this that compositing via FLTK is pain in the ass (I had to reimplement FLTK looping in evoke so popped windows could be redrawn and receive additional events), plus all the "nice things" related to the spawning externaly requested programs. Pfew!

You probably ask by now how all that worked together? Most of it did, but it (still) had a big problems with events of dialog windows that could pop up in every moment: some of them didn't show up, some didn't receive events... pretty bad things for something that will hold desktop session.

So, instead digging for another "fix", time was to get serious and dump everything not related to it's mission. Even before I planned to move compositing code in window manager (where it belongs) or as an independent program (even better solution) and all that "runner-launcher-watcher" code was a mistake. Vedran proposed to keep most of this background stuff in one program (to reduce a memory usage by running only one instance), but it ended up using even more memory not counting (possible) instability due races. At some point, we can addopt old elauncher (runner from EDE 1.x) to communicate with already running elauncher instance via D-BUS or some other IPC so it does not get's duplicate with each new started program. Just an idea...

To get in new evoke... maybe the biggest, user visible thing is a small addoption for the splash themes. You create a folder and put a background image and few icons and voila, job done. I had no clue how splash theming should looks like because every other desktop is doing it in different way (they done it mostly via "engines", but why you should write a C/C++ code just to add different splash screen).

So, in that folder you just plop "background.png" (it has to have this name and to be a png image) and a bunch of icons and their name associate with program started from "ede-startup.conf". Remember this name, since it will holds everything needed to fully starts EDE.

Here a small shot of the-5-minute-created theme, called "scape":

There are few things in my head planned to be added, like customizing where icons will be placed, icon jumping-blinking-or-else effects, progress text font/color and etc. They will definitely require a special file, specific to each theme, but let's not hurry; these are features and features can be added later.

Some stuff on ede-look.org

2009-02-13T06:00:00.000-08:00

Just uploaded two screenshots and logo at http://ede-look.org site. It would be a shame not to use what opendesktop.org guys offered to us :)

Interesting thing is that you will not get screenshots visible by default; instead you will have to click on "Screenshots" on left side and after new content is loaded, find "don't show screenshots" and unselect it. Odd, I know.

So, if you feels a little bit arty, feel free to create an account and add something. Screenshots, wallpapers, refreshed logo(s) or anything EDE related, crazy or not, your playground or something completely new. Show us your talent!

Btw. those fonts you see, I didn't put them :) Seems they are added so pages does not looks empty.

Release tags maintenance

2009-02-11T06:05:00.000-08:00

I just little bit reordered tagging schema in repository tags, mostly for better readability. Instead previous v1_0_2 and v2_0_7 (inherited from cvs), where you didn't know what release version is for efltk what for ede, now we have much better names (e.g. ede-1.0.2 and efltk-2.0.7). Not to say how will save us from ambiguities when edelib and ede (both tagged as 2.0) are added.

One thing made me mad: subversion had to store these changes. Thanks God history for each file was preserved, but couldn't be nice if I could say "svn move x y --and-do-not-write-history", since I'm just renaming directories not related to the final tag and do not want it in file history changes (err, because file history changes are related to the changes in file not to the parent of it's parent directory renaming). Or they are maybe related...

Playing with logo

2009-02-06T04:18:00.000-08:00

Few days ago, after I compiled latest Inkscape, I played a little bit with EDE logo mostly as learning (or refreshing) process with Inkscape and to see what a new version brings. So here it is (warning, programmer art is following):

Interesting thing is that in Inkscape some very cool effects can be created in a few clicks, allowing you to experiment a lot. Meaning this: you can start with some blury idea (or no idea at all) and complete with amazing art. Of course, in artistic hands this goes to the whole new level.

Bad time for SkyOS

2009-02-05T08:07:00.000-08:00

Looks like SkyOS is having some development issues and author is stipulating further development paths.

On one hand, I'm finding SkyOS project pretty amazing with great respect for it's creator; everything is done by one man, from kernel to GUI and apps and these news are sad. On other hand, if author makes it open source, I'm thinking it will be a great win (for author and users), not to say how I will finaly get a chance to try it without paying for it ;)

Stop Software Patents Petition

2009-01-21T07:32:00.000-08:00

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!

Config class locale fix

2009-01-20T04:53:00.000-08:00

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.

ede-look.org

2009-01-15T01:05:00.000-08:00

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!

No more builtin paths

2009-01-14T07:47:00.000-08:00

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

ede-screensaver-conf refresh

2009-01-13T03:50:00.000-08:00

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...

No FOSDEM this year either

2008-12-31T04:51:00.000-08:00

Looks like EDE will not have a chance for presentation on FOSDEM this year. Again.

Last year I tried to apply for stands (I know, I know, trying to go far) and only the big ones got a chance. I was pissed for that. Don't get me wrong; I wasn't all that mad for rejection, but also for seeing each year on each conference 10-20 well known projects that will give me "the news" I already know. If you don't believe me, then just see the difference between this and previous year.

Seems that Lighting Talks are the only fresh part of this event; each year there are new or soon-to-be-known projects mostly due some rules (e.g. you can't be twice). Can those rule be applied for stands/devrooms too? Looks like not.

Now, rejection is probably our falt too: there was release a year ago and the current 2.0 development is in progress, maybe too slow for the eyes outside it. You know, it's a little bit hard to say: "I just got edelib::list pointer specialization and proves it wasn't so good" or "ede-screensaver-conf will now communicate with xscreensaver via X messages" to someone who is not familiar with these. Even if that person is familiar, I'm sure he/she will not waste their time on reading commit logs.

But, things are not that bad: a new year is comming and will see what will bring us :) And of course: Happy New Year!

EDE in "6 of the Best Lean Linux Desktop Environments"

2008-12-03T06:27:00.000-08:00

Looks like EDE got attention on LinuxLinks in 6 of the Best Lean Linux Desktop Environments article. I just find out about it via osnews entry. Cool!

Late on party

2008-11-24T03:11:00.000-08:00

Seems I have a good sense of comming late on party. Checking a deadline for stands on Fosdem 2009, looks I missed it a few days ago :(. But, even if I sent a request, there is a highly chance it would be rejected, as it was before (you know, you have to the big/famous project which pisses me off).

So, I will try to apply on Lightingtalks, as advised by one of the Mozart developers. We will see what will happen...

Scheming things

2008-11-13T05:02:00.000-08:00

During some spare time in last month, instead putting some efforts in EDE, I played a bit with some scheme implementations, notably Gauche and Clojure (ok, ok, Clojure is not scheme, just don't yell :P).

I will omit Clojure here since there is a lot of buzz about it over the net currently (which is good), and even a book is comming soon. Yes, it deserves all that buzz :)

Gauche is, on other hand, pure scheme aiming for scripting stuff and if you are interested, for embedding too. Important thing, at least for me, is a fast startup (a thing where Guile sucks badly) and ready network-xml-opengl-clos-etc libraries. Also, you don't have to wait eternity to compile it (like PLT or Ypsilon) :P

Curious thing is that Gauche author merge in it experience earned in Final Fantasy movie (yep, there was a lot of scheme code in that movie), and he nicely put all of it in some of his essays (reading advised, even if you don't like scheme language).

Since this is not a review but mostly a few words finding excuses for recent little bit rare commits in ede2 module, I will end here. I'll have to play with Gauche more for a final impressions :).

Cute icon theme

2008-10-24T07:19:00.000-07:00

Vedran just pointed me to very nice icon theme named OpenWorld. Too bad SVG files are not available yet since there is a very high level of interest for them (as I can see from the comments).

For now, we'll have to be happy with 48x48 size only.

Distributing programs correctly

2008-10-15T03:53:00.000-07:00

One of the things I like in Chicken scheme is one of the cleanest distribution model I ever seen. For some it will look, at first, very ordinary or they will not notice it at all (at best) but... shouldn't The Right Way be the program installation without noticing that procedure at all?

I never was a fond of distributing own binaries (except a distro specific packages) on Linux; you never know what the person who downloads it has. Does it have correct glibc or stdc++ or whatever libraries you are using? Just bump the source archive and let configure do the magic.

But in Chicken case, things are different. You simply download the binary and extract it in / directory.

Later, you find out you are missing the big integer support (not enabled by default), simply telling "chicken-setup numbers" in command line and "(use numbers)" at the beggining of the program will brings them.

And at the end, you want to compile your code, "csc yourfile.scm" will do it.

Now, can things be more simple than that? You should not be worried will Chicken's binary works on your Linux distro nor what are the eggs, nor how "chicken-setup" resolves egg dependencies, finds and downloads them and at the end, compiles and installs them. Nor how "csc" calls gcc at the background to perform final translation of generated C code to the binary.

Everything works.

Now, when the big names or the big programs will have the similar thing with the same (or at least similar) easiness?

Code prettyfier

2008-10-13T06:37:00.000-07:00

Just played with a Google's code prettify and after following these advices and these, code highlighting is available here too.

Let we see what it can make...


/*
 * some C/C++ code
 */
class Foo {
private:
 // nothing
public:
 // nothing
};

void baz(void) {
/* nothing too */
}

Some python code:


# a comment
def foo():
   print "bla"

And scheme code:


(define (func a b)
(+ a b))

Looks like it works :)

SunStudio journey

2008-09-23T02:27:00.000-07:00

Some time ago I managed to get (read as "downloaded") a SunStudio toolchain; it is always nice to see what alternatives could look like and/or to prove how badly gcc sucks these days. Unforunately, lack of time left only few "Hello worlds" compiled with Sun's product, a quick usage and compilation speed test.

Last night I decided to take things thoroughly: to put edelib on test with this compiler. The truth is that gcc spoiled us a lot. At least on everything except Windows.

Things are pretty consistent across the versions (sans ABI changes): switches and flags are mostly the same, errors and warnings too. Almost every person who was using it more than a few monts will immediately grasp what was wrong by just quickly scanning a few first words of the error report.

Now, taking part with Sun's compiler reminded me on those Windows days when you wanted your application be compiled with as much compilers as possible; so you could stick "extremely portable" on it. And those days were painful. You would spend most of the time reading compiler documentation, fixing build system to support special flags that should made your program runs faster and, at the same time, be smaller.

To the present time: after few obscure error messages ("mister, you are implicitly casting from void* to char*") I started to question my knowledge about type promotion in C, until I found that I was compiling a C code with a C++ compiler (in a Sun's vocabulary, "cc" is C compiler and "CC" is C++ compiler); actualy, during some play I left CC and CXX environment variables to point to "CC" and configure script happily picked it.

After fixing that, things started to roll with some strange "Warning (Anachronism)" and "Warning: i hides Fl_Window::i" (where first "i" is local variable and second is private Fl_Window member; different types of course) and, at the end, things failed in the linking stage with "undefined reference to __mangled-junk-names__".

Aaaaahhh, I'm compiling with a different compiler and it should provide own C/C++/whatever startup and standard libraries. So, adding Sun's "libCstd" and "libCrun" fixed it. After this, things finished successfully, at my suprise.

Hm, it shouldn't be this way; it should be much harder.

Going through the build scripts, I found thing I missed: programs would, by default, link with libstdc++ (gcc's C++ standard library). Why would I want to link with it, when Sun's compiler comes with it?

Removing that and linker went crazy with "undefined reference to new and delete operator family"; a common error in gcc if you miss to link either with libstdc++ or libsupc++ (libsupc++ have only these operators and is perfect if you don't want all that STL stuff with you). So, after putting libsupc++, I get another monster: this time undefined reference to gcc's internal functions like "_Unwind_Resume" and such. Huh boy.

This error will pop up usualy when you feed gcc with -nostdlib or -nodefaultlibs flags; they will omit all libraries gcc secretly put behind your back. Usually no one should mess with above flags except they feels masochistic or know their business. One of those secret libraries is libgcc (guess) and there are _Unwind_xxx functions.

After addition, linkage went fine. Hm... again I'm missing something: why would I still link with gcc libraries? Then came up: FLTK was compiled with gcc!

Now, FLTK rebuild with Sun's compiler and another edelib rebuild (this time without libsupc++ and libgcc) yielded correct linkage.

And, at the end, a small comparison of sizes generated binaries. First of all I didn't use advanced options for both compilers and I just put "-O2" for gcc and "-xO3" for sunCC so this comparison should not be used as the final word; out there exists a much deeper comparisons.

I compared sizes of libedelib library, efile and elinks from examples and run_test, a program that links a bunch of tests.

And here are they, with all sizes in bytes:

gcc:

libedelib.a 331794
run_tests 367824
efile 95459
elinks 73617

sunCC:

libedelib.a 384330
run_tests 498964
efile 106045
elinks 85863

I quickly "time-ed" run_test and elinks (elinks against a larger html file) and here they are (results are in form real/user/sys):

gcc:

run_test: 0.17/0.03/0.02
elinks: 0.09/0.07/0.00

sunCC:

run_test: 0.19/0.04/0.04
elinks: 0.11/0.09/0.00

Results are pretty similar, favoring gcc. Of course, exploring and putting specific options from both would yield faster and/or smaller code. I'll have to play more with the sunCC's options.

At the end, it is nice to know that both FLTK and edelib compiles nicely on Sun's compiler. This makes (almost a clear) path to port existing EDE 2.o code on it.

BTW I was using SunStudio 12.

New naming scheme

2008-09-21T12:15:00.000-07:00

As a product of few requests and a longer discussion on forum (small part was on ede-devel, but looks like the web interface is not refreshed yet), EDE will soon addopt a new naming scheme for applications.

At first sight it looks pretty GNOME-ish, but it is for the reason. Or maybe there are more than a single reason :)

All our applications started with "e" denoting part of EDE (in the KDE style). It was fine until you install applications starting with "e" too, like applications from Enlightenment folks. And you suddenly get: eiconman, edewm, eet... a pretty confusing list where you don't know what is what and what belongs to whom. If you want to reuse all the beauty of the shell completion using "e" as the starting character... things becomes pretty messy.

Adding to this confusing names inherited from 1.x version, this new naming scheme comes as rescue.

Let say you do "ps -ef" to list all the processes and just to check what is eating you memory or cpu, and suddenly you see something like "eiconman". "What the hell is eiconman?", I'm hearing already. Sounds like "superman". Actually it sounds like everything except "desktop" (as desktop with icons in your background).

Yes, "eiconman" is short name of "icon manager" (omitting "e") but icon manager is very broad name and the first thing it associates me is some daemon that manages all visible icons on all opened applications, no matter was that FLTK or Qt or GTK+.

Now, you replace it with "ede-desktop" and things becoms much better. When you see it in that "ps" list, you definitely don't want to kill it or, when it crashed, you'll know how to start it (if you decided to go little bit deeper and help us ;)).

As Ralf commented, shell completion comes free in this case. Of course, there is other side of all this goodness: things could become too verbose, like "ede-do-this-do-that-daemon" and will not be pleasant to type without some shell help. But, you can't have everything.

So things will be keept much more flexible than consistent; e.g. "efiler" sounds better that boring "ede-file-manager" or "evoke" is much more practical than "ede-session-holder-app-starter-and-shutdown-manager".

Btw. things are not changed on the repo yet; hopefully, I will change that during the next few days.

Fixing other's mistakes

2008-09-16T06:06:00.000-07:00

In a recent discussion with eNjoy (yep, there should be some media player and I'm hoping it will be usable soon) developer, I found that Ubuntu does not installs FLTK correctly or at least packager missed few important things.

FLTK keeps header names under .H extension; I'm not sure why is this, maybe legacy stuff or due some strange platforms that likes C++ header files ending with .H and source files ending with .C (FLTK uses .cxx here). And since everyone expects .h extension for headers no matter used C or C++, FLTK plays fair here too: installation procedure will create .h symbolic links to those .H files (I'm aware of attempt from C++ purists to keep C++ headers under .hpp extension or no extension at all, like headers from STL, but I'm finding this practice little bit disgusting).

Now, as you guessed, I used .h for FLTK normally as for any other header file all over the code (edelib and ede 2.0), not thinking that some packager will mess things up. Maybe they see this as perfectly normal, but shouldn't distro package resemble the state "make install" or whatever created?

So, latest revisions of edelib and ede2 modules have fixed this "issue". Hopefully, things are less distro dependent now, but, as usually, you never know...

edelib on SunOS 5.7

2008-09-10T04:12:00.000-07:00

Just putting a first impressions after compiling edelib on SPARC powered Ultra-1 SunOS 5.7. This should be, according to this page, Solaris 7 or Solaris 2.5; I never managed to get into this naming scheme.

Ultra-1 always associated me with durability, a feature not known for today's computers. Just when I remember what we did with those few pieces in our lab, how much they were forcefully shutdowned (by plugging out power cable) and how much data they crunched with 200 MHz cpu's... and they still happily running today. Without a problem. That is a quality!

For those unlucky who have no clue what I'm talking about, here are detail specs with images. In short, a very old computer, powered with 64-bit UltraSPARC 200MHz processor and cca. 32 MB or RAM. A perfect piece and platform to test against.

To be honest, some time before I checked edelib status on this computer (ChangeLog says December, 2007) and things changed a bit since that time.

So what we have here? First of all, D-BUS compilation was disabled; I neither don't have nerves to compile it and, most important, I'm lacking space on hard drive (just another indicator how modern software is bloat). I had to disable it manually (commenting parts in Jamfiles and removing checks for pkg-config, because it was not present), but that was 1-2 minute job.

This gave me a nice TODO: some option to disable D-BUS in edelib (during configure phase) would be nice and, when given, should only skip compiling Edbus code much like --without-x does. edelib also utilize --without-x and when given, all code with FLTK involvement will be omitted during compilation (with X11 parts of course). And was used here.

After these preparations, configure script did it's job, reporting small syntax error during XDG mime database presence detection; some csh quirk and should be fixed soon. Compilation then died on regex.h (GNU regex library copy used internally) due some gcc extension (nothing that #ifdef can't fix), which was pretty good; I thought things will be a lot worse :)

Next target was to run tests. Here is the result:

Tests: 55 Passed: 52 Failed: 3 (time: 0.26)

Those 3 failed tests were:

test for mime types since database wasn't installed
test for directory functions; check was for "/root" and Solaris does not have it
and test for binary presence; there are some hardcoded values in test which are standard for Linux systems; Solaris places binaries somehow differently

So, nothing critical. The last thing was to try some tests with the new IPC code I added and after few linker Undefined... errors, additional linking with libxnet was solution (in this library Solaris keeps networking primitives). Test worked as charm :)

ADDON: I just modified build system so shared library could be created too.

Now, the real job would be to compile and run current EDE 2.0 code here. That will be left for the future ;)

Libtool, oh libtool

2008-09-02T04:45:00.000-07:00

...goes bye bye from edelib. At last :)

I never liked this tool, but I put it in use, thinking it would save me from messing with shared library creation. And it saved me, indeed, taking my full focus from shared libraries to libtool's own quirks.

For example, those command line options does not work. Or at least, does not do what their names suggests or what documentation said. And, after few tunings those things started to work, going to another computer with another libtool version, everything crashed so nicely yielding very sweet error reports that only libtool can give you.

Maybe I made a mistake using libtool directly, not via AC_PROG_LIBTOOL macro (that does some wizardy behind), but why program exists anyway if you can't use it directly? And in my case, there is no Makefiles nor Automake and AC_PROG_LIBTOOL will be happy if they are used (or you will have to play a little bit with $top_builddir).

Now, a third rewrite of SharedLibrary rule (in edelib Jamrule) finally starts to show some maturity behind ;). Symbolic links will be created, soname will be correctly set (actually not as libtool prescribes but it is easy to "fix" that) and in last commit, even .la files will be created. It is good to be libtool friendly, even if you don't use it.

The only thing left is to see how this will behave on other unix platforms (and other compilers) :P

Rusty on CeePljusPljus

2008-08-29T03:26:00.000-07:00

Rusty Russell have some message for C++ (l)users and here it is. Short and sweet :P

No more sound

2008-08-25T07:06:00.000-07:00

edelib will not play sounds any more. I just removed sound code from it which was pretty buggy, especially asynchronous playing. Actually, the only asynchronous part was buggy, mostly due quick threading support addition.

Alternatives? Two possible options that I'm thinking currently: use Audiere (maybe fork it), a very good sound library or develop own. Or maybe use both ideas; Audiere have very cool API and it can be inspiration for EDE sound library design.

Why Audiere fork? Besides cool API, there are few things I would like to change and remove; also the last update on the web is dating on 2006 and repository code gets updates from time to time (like recent native ALSA support addition).

Looks like EDE 2.0 alphas/betas will not have sound support; probably even official 2.0 will not have it. But I' m hoping it will not last too long for it's addition.

-pedantic anyone?

2008-08-23T04:50:00.000-07:00

Everyone talks how C++ plays nicely with C? Of course it plays, until you engage somehow stricter validator in that compiler. After that, you are on your own...

During my recent emountd cooking (new EDE mount/unmount HAL-lified notify daemon) I was surprised that you will not be able to compile program that uses libhal with -pedantic flag: syntax error! Not to be expected for a product from people knowing their business...

I got this:

...found 95 target(s)...
...updating 2 target(s)...
C++ emountd.o
/usr/include/hal/libhal-storage.h:283: error: comma at end of enumerator
list
cc -c -o emountd.o -Wno-long-long -Wall -pedantic -g3 -D_DEBUG -I..
-I/opt/ede/include -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/hal
-I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I. emountd.cpp
...failed
C++ emountd.o ...
...skipped emountd for lack of
emountd.o...
...failed updating 1 target(s)...
...skipped 1
target(s)...

Hm, at first I was thinking compiler went nuts after 5 hour compile/recompile torture; you know, I get used to errors like this in my code, but in code residing in /usr/XXX... that is completely different thing.

So, quick peek in that libhal-storage.h, revealed this:

typedef enum {
// formatting mess so list is reduced
// ...
LIBHAL_VOLUME_DISC_TYPE_HDDVDRW = 0x0f,
LIBHAL_VOLUME_DISC_TYPE_MO =
0x10,
} LibHalVolumeDiscType;

See last LIBHAL_VOLUME_DISC_TYPE_MO and comma at the end? Well, both C and C++ standards said "no no" to that, and -pedantic is here to reminds you on that. Not only for these syntax changes, but for C/C++ difference too; at least those that C++ didn't adopted. The main example is long long type: not yet supported by C++ standard.

Not problem a much, except now you will not be able to compile D-BUS code with g++ and -pedantic! And long long is very much used in it.

Besides emountd, this problem I had in edelib too, at least in D-BUS binding code.

Possible solutions for this mess is to either forget on -pedantic or to add -Wno-long-long, where warnings/errors about non standard long long will be inhibited. Since I like -pedantic, you know what I went for.

Btw. just checked: that issue with libhal is fixed, so I'll have to think how to remove -pedantic in 0.5.9 version (not sure about previous/later). Ah, yes, we have autoconf for that :P

EDE Documentation System

2008-08-15T19:08:00.000-07:00

...or: how writing docs can be fun (hopefully).

I'm aware that documentation in EDE 1.x sucked a lot. We had a few html pages with less content than official docs have (yes, I'm also aware how that web documentation sucks too). It contained something like: "Get EDE from", "Very quick install", "Join EDE...". Nothing fancy. But not good either.

Those html pages was quickly assembled with Mozilla Composer and Composer is not known for generating a nice html pages editable with ordinary text editor. At the end, no one had enough inspiration to update it, yielding a situation where some very cool things remained unknown.

You know, developers hate to write docs. It is true. Is it due laziness or because after 5-6 hours of coding you don't want to touch editor any more or, maybe, documentation tools are simply bad, I'm not sure. There could be an influence of each of them.

But, on other hand, zero documentation is not good either (or you will not be able to say: "RTFM!").

Today, when you say "documentation", you will hear instant reply: "DocBook". It is standard, well defined system with a lot of tools to convert it to almost any known documentation format. And is also a good system to inspire you for no writing it at all.

Without a good howto you will not be able to write anything and even after that, keeping reference book under your pillow is a good way to save you from errors and... to speed up writing. You don't want to spend the whole day on only one page, aren't you?

So to save my typing hours on something better and to have a good excuse to reject any program without documentation (or patches without docs updates) :), the only solution was some generator with sane markup. Or markup that most people already knows. And it should produce at least docbook files or something like that, so docbook can be generated.

A good candidate for this was Doxygen. Markup syntax is very easy to pick up and almost all distros already comes with it. Besides html output, doxygen can produce xml output too; theoretically, we could use some xslt processor and produce docbook files from these xml files (that is why xslt exists).

Since I'm not good with xslt (and don't plan to be), I tried to find something already done, or at least "almost done". Unfortunately there is no such a script (or xslt code; call it whatever), or I wasn't able to find it. Something very similar I found as part of Boost libraries and it was generating some intermediate format (named as boostbook or like that) which is then converted to docbook.

How is done, it still remains the mystery to me: they complicates everything, even a build system!

I tried a few more tools (really can't remember now), until I found it: AsciiDoc. It is a python script (a single file!) without external dependencies and does not mandate installation to be used (which is important too, so we can distribute asciidoc without thinking if user has it installed or not, which version and so on).

The first thing that appealed me is simple markup syntax it uses; almost like you are writing an ordinary text file (well, you are writing a text file ;)).

Here is the sample:

Some title
=======
Bla bla bla

Subtitle
--------
Bla bla bla

and so on. The best example is asciidoc user guide generated from this file.

Next is a number of outputs it supports: besides docbook (out of the box, man!) it can produce a html, xhtml and man files; plus everything else that docbook can spit out (for example to create pdf output, it will create docbook files first then will convert them to pdf via docbook toolchain). Almost perfect tool :)

The only thing left to be done was integration with our build system. I decided for straight html without docbook as intermediate format: asciidoc creates very nice html pages and (most important) docbook toolchain is often not installed (at least I don't install it ;)).

Due jam's flexibility, asciidoc jumped in fine; the only thing you should put in your Jamfile is this rule:

EdeManual foo.txt ;

That is it. When jam or jam doc is run in console, jam will, via asciidoc, convert given files, move them in the special directory assembling EDE Manual and installs it in appropriate directory, when jam install is given. Couldn't it be more simple ;)?

On other hand, documentation quality is story for itself...

Post #2 (part II)

2008-08-13T07:24:00.000-07:00

...continuing...

If you are going to ask where to find that Jam, below I was talking about, I will mention that is already on our repository. This should ensure two tings:

easier finding and download
ability to hack it if I find something I don't like

You will notice that out there are few Jam derivatives, notable FTJam, BoostJam and maybe less known HaikuJam. We are using HaikuJam (due few useful ablilities) and it is pretty compatible with original jam (a.k.a. "Classic Jam") and ftjam. BoostJam is sad story for itself and it should be avoided for EDE.

What about rest of DE? From the "big three": edewm (window manager), eworkpanel (panel) and eiconman (background with the icons) only eiconman is very much refreshed. Refreshed in a sense that was rewritten from scratch (three times!!!) and is near completition.

This looks like a slow progress, but I'm not thinking like that. There are many small utilities and programs that are added, revised or removed, notably a very good file manager (efiler) that is Vedran working on.

And besides, I'm still following a plan to ship a first alpha without finishing window manager and panel (and partialy eiconman). They will eat up too much time and also I would like to try some new ideas I have with them. In the mean time, edewm and eworkpanel from 1.x should be a temporary replacements.

Ending with this "quick view", I realized I said almost nothing about new things; probably seeing that each of them will require it's own post. Which is planned in the near future (hopefully) :)

Post #2

2008-08-12T10:41:00.000-07:00

Wow, I'm actually writing something here; already at the second post :)

I feel obligated to put a quick view of EDE we are working on now. That view is about differences with old, efltk powered version, architectural changes and so.

I sumarized some things before. Some of them changed, some not (so there is no need to write about latter). The biggest change (from EDE 1.x) is that famous switch to FLTK 1.x and integrating freedesktop.org standards. This maybe sounds "no too much", but these short sentences are often proved to be opposite. And it is.

EDE 1.x was so tied to eFLTK (which extended FLTK just for EDE needs) that doing simple "compile on FLTK" was simply impossible (since eFLTK was based on first versions of FLTK 2.0, API-s between 1.x and that 2.0 was very much the same, but under the hood, mostly layouting code was totaly different; later FLTK 2.0 API went crazy which is story for itself). Now you see why I put "impossible".

That was clear indication that we should either dig into eFLTK and remove GUI parts (because you know, we would use FLTK 1.x that already provides it) or to start things from scratch, learning from eFLTK what we need and what not. As you guess, we went to latter; now you should have a clue what is edelib module on repository.

Basically, edelib is what FLTK does not provides (which is good or it would be too boring) and what we don't like in it. Plus things we would like to have. And plus freedesktop.org specific things. Enough said.

Here is the one curiosity: EDE had a library named edelib once, which had also needed things for EDE; later it evolved into eFLTK. I'm not sure why; probably due FLTK 2.0 "never-released" curse or else, since I was not part of the project then. Original edelib code was lost when I did a major CVS cleanup which had a tons of started but never finished programs. Probably I made a mistake; probably I should moved everything in a separate module for history reasons, but I can't recall why I didn't. The only thing I know is I had it on my hard drive, which died long time ago.

But, believe me or not, name of the current edelib wasn't choosen due history; it simply popped up, probably inspired by kdelibs for KDE (Vedran when joined to EDE did some work for KDE so you know where inspiration could came from).

So, due those history reasons (and to follow EDE versioning), current edelib is tagged at 2.0.0 version. Just in case you starts to ask when we released edelib 1.0 :)

Second major chaged (or third, lost in counting) is that we are using Jam. I never liked automake; in EDE 1.x we had our own build system, much more like FLTK have and was very limited. You couldn't say "give only to foo.cpp -D_BLA_ flag" nor "link edewm with libdemo_debug.so but the rest with libdemo.so" without writing make code, which is a good chance to yield unportable code between implementations even in the simplest form.

Ah yes, our build system used "recursive make feature", mostly because is very easy to write it without complicating the matter. So, we managed to learn how this was bad when obvious changes in the source files wasn't registered and rebuilded (see Recursive Make Considered Harmful for more info).

Jam does not have these problems; hey, it even allows you to write own, sane "build library" (example is autojam) and to overwrite builtin functions (in jam vocabulary it is a "rule"). Not everything is very bright: jam introduce it's own way of managing dependencies, which is pretty alien to "make commers"; documentation badly sucks giving incomplete information about latter (which is very, very bad since your project will not be built)...

But, small source size (binary too), easily hackable code (I think so), speed (did I mention how it is fast!), damnit good per target (file, target, pseudo target, soon-to-be-generated-file, just name it) options (set per target variables, call functions, etc.) are good arguments to forget flaws. And you don't have to run "makedepend" since it will scan every header in given build files automatically.

I'm lacking of inspiration; remained stuff I will try to finish next time.

Intro

2008-08-10T17:41:00.000-07:00

Huh... here it is, my second attempt to create and use blog (second attempt in a sense of "I had it few years ago and was too lazy to update it" not "I couldn't create blog account here" :)).

I know you got it; I'm just trying to get used to typing here ;)

So, why I'm doing this again (implying if I'm lazy to write blog)? Well, that "few years ago" was when blogs was hot stuff and the time when projects started to adapt it. Also, in the same time, Vedran (my co-developer on EDE) was accepted in the first Google Summer of Code as part of some Ubuntu project (lightweight desktop, if I can recall). Of course, EDE was part of it too :)

Ubuntu mentors requested students brings their blogs online so they can track their progress(pretty much the same GSOC mentors do today); Vedran assembled WordPress (was pretty complicated those days; was that WordPress or was something else?) on our LUG server and started to scribe. I joined too; not as part of GSOC, but to give insight of other development side too, wrote few posts and find out that blogging wasn't for me.

Things changed in last two/three years a lot; today there are more projects with blogs than opposite and users likes that. Users expects to see a progress, nicely worded things what is going on and not to track developer lists with developer talk nor (for God sake) to track repository changes and read commit logs.

And my habits changed too! Today I'm first checking (for project I'm interested) blog writings then mailing lists and release dates. Often release days or high volume mailing lists means nothing; releases can have minor changes or changes I'm not interested in, mailing lists talk can be (and often is) about weather or movies. Not to mention how hard is to get some useful information. Mailing developers? Sure, just how long they will need to respond and what quality of response will be (bad quality does not mean they trying to be rude, just lack of time).

Blogs are, today, part of development tools, like bug trackers, wikis and mailing list (implying blogs about software development).

Just my view :P. Now to something useful...

People often mails me about EDE progress, what is going on, when will be release and so. Few fellows mentioned online that development stalled or slow progress is going on. Yes, the latest release was almost a year ago.

I was often replying on this via "We are alive, just too busy with EDE 2.0" and "Something soon will pop up" and similar. Yes, I know this is not enough; reading few times that "...we are working hard..." without anything useful is a good chance to drop my interests in that projects, seeking for alternative.

But, there is some truth :P. We are working indeed and there is a lot of changes out there; to summarise everyting in one document or mail would be very ungratefull. So I'm hoping these posting here will try to inform you little better about progress and things under the hood.

On other hand, if I get bored or tired with this blogging stuff, I will probably return to good old mails :)

Anyway, enough for the first intro post. Hoping to came with something better next time.