Moved blog

I moved to the new place: http://acidwords.com. See you there.

Fl_Highlight_Editor 0.2

I've pushed new, 0.2 release of Fl_Highlight_Editor widget. This release is actually a set of changes collected after 0.1, which happened almost a year ago (huh).

Quick changelog:

• Added fluid-mode, html-mode and make-mode; modes for editing named file types.
• Extended language so user is able to change cursor shapes and FLTK font faces (not to be confused with Fl_Highlight_Editor faces).
• Added support for named and HTML colors; in previous iteration only FLTK colors were allowed (e.g. FL_WHITE), now you can use e.g. #a4a3a3 or aqua.
• Manual update, a bunch of small fixes and more...

Let me know if you find some issues.

Ono, a small and friendly Offlineimap frontend

After a bit longish hiatus, here is the new project I managed to hack in the last two days. Nothing big and nothing fancy, but usable for me and, hopefully, for others.

I've been struggling with mail clients for, let say, last 2-3 years. The first client I started seriously to use was Mutt, some 9 years ago. At that time, when I first read Mutt famous catchphrase:

All mail clients suck. This one just sucks less

I had no clue why this guy was so full of himself. After all, I used MS Outlook for business mailing so transition to Mutt was like moving from nice Mercedes to 100 year old broken bycicle. BUT...

You know, good tools gets under your skin (in positive context) and you notice that when you attempt to switch to alternative. As someone once said, good tool is invisible.

Anyway, to make this story short, after all these years, various Thunderibirds (btw. the last iteration looks awful; for God sake guys, what are you doing!!), Gmails, Gnus-es and not-sure-what-else, I still can't find viable alternative to Mutt. Sure, Mutt isn't perfect: multiple mail accounts handling sucks badly, IMAP/SMTP can be much better, configuration; oh boy, it is like Sendmail.

But the speed, shortcuts and everything-can-be-configured approach: unmatchable!

So, to bring Mutt in 2010 (not a typo :P), where we operate under desktops, have system trays, notifications and good IMAP libraries, I created a small project called Ono. Ono isn't Mutt specific; actually, I created it to make Offlineimap usage easier. As a matter of fact, with Ono, you can use any mail client, as long as Offlineimap is used for mail syncing.

OK, I lie; you don't have to use Offlineimap either. Thanks to builtin scripting language, you can use Ono to place in your system tray whatever you like: terminal programs, GUI programs without tray support, name it.

You can download 0.1 version and play with it. Be warned: documentation needs some love as there are couple of hidden gems I didn't mentioned in README file and, I can't promise it will not crash :)

Upgrading Fedora

Imagine you have computer running Fedora 19 and you use it for daily tasks. Imagine you are happy with it, especially when you do run yum update (sic). Now imagine you decided to upgrade your bellowed, happily running system to the next major version.

Sure, you head directly to FedUp site, assuring you are running the latest version (because they messed up previous versions which could render your system unbootable), and with the fingers crossed, you fired it up.

Now imagine, after a half an hour, you get this message:

WARNING: problems were encountered during transaction test:
  broken dependencies
    libvpx-devel-1.2.0-2.fc20.i686 requires libvpx-devel-1.2.0-2.fc20.i686
Continue with the upgrade at your own risk.

More than fifty years of computing and research in IT field, with all sorts of methods, algorithms, object oriented, dynamic, functional and what else languages, and resolver figured THAT out?

Autumn cleanup

It's been a while since I put anything here (whoaa, 5 months!) mainly because of personal issues I had during that time, which required my absence from the project and usual things.

So, I'm slowly getting back. Unfortunately, this absence period delayed planned EDE release and a bunch of stuff I planned to do in the mean time, and, for warming up practice, here comes small autumn project cleanup.

emountd, a small HAL abstraction routing daemon was removed. The main intent was to provide manageable way to receive events from various devices, without linking every program with libhal and required libraries. As usually, we got something worse as replacement; not even sure what exactly is today, systemd or some *Kit crap.

Because of that, planned mount listener (where you would get an icon on desktop when you mount some device) will be left for the future. Things are hairy now for anything normal and portable.

The second cleanup thing is documentation moving, better to say, overhaul. EDE 2.0 shipped with asciidoc, used to build application specific documentation and combine everything in EDE Manual. I modified it a bit to make it easier to automate from build process, but it requried a serious update: official asciidoc already progressed a bit, some python 2.x idioms were deprecated and more and more distributions are shipping python 3.x by default (asciidoc was written in python).

Thanks to awesome kraileth, EDE Wiki is much better now so why not to move documentation there? Everyone could edit it without repository access, which is the main point of one big fat manual: more eyes, better content.

Fl_Highlight_Editor, editing widget for FLTK

Last couple of days (and months) I was secretly working on a new widget for text editing under FLTK, Fl_Highlight_Editor.

FLTK is missing a good editing widget with code highlighting capabilities, so I gave it a shot adding some new concepts; not revolutionary, but how many text widgets comes with a scripting language? ;)

Having extensible editing facility, where you can easily add new language support without digging in C/C++ code isn't common. My favorite, Scintilla isn't ready for FLTK (actually there is no available port for FLTK) and all syntax highlighting capabilities are added by subclassing C++ classes. Means, you have to recompile your binary if you want to add or modify something.

So, I tried to find inspiration in editor of all editors, Emacs. Sure, that >50 MB monster isn't model for embedding, but some concepts like small core and everything else written in extensible language sounds quite interesting. By using similar design, widget user can easily remove parts it doesn't like or only add one he/she likes. For example, editing and highlighting support only for language X, where scripts could be embedded in binary (or not).

Scripting language I used is Scheme; better say TinyScheme, which is still the only awesome interpreter I could find, bundled inside 4 files, that doesn't suck. Extensible language (the language which you can extend without digging inside interpreter) where code is data, is a great deal: you can easily experiment with the syntax, have so called configuration files without external libraries or additional code and the best of all, have fun using it.

Initial Fl_Highlight_Editor version comes with modes for C/C++, Python, Scheme and Markdown; not advanced as Emacs modes, but capable enough to highlight known patterns and setup TAB width depending on language. Sure, there is a lot of work, but ultimate goal is to keep the whole package simple, but flexible enough for adding new features.

Happy usage :)

Building shared libraries with Jam

Jam is one of those tools I really admire: it is small, lean, fast and you don't have to be a rocket scientist to hack it. The best of all, it is so ahead of make you will wonder why you didn't use it before.

Ok, above paragraph very biased, but adding Jam to EDE solved a lot of portability problems we had before and introduced some new, which is story for itself. What matters most, with Jam you can write true build library that you will reuse between projects.

Sure, writing reusable build library with make is possible too; you need autotools and you write a little bit autoconf, then a little bit automake and everything you pack in a nice M4 script. Don't forget to use appropriate shell syntax or odd things will happen between platforms.

No more ranting... One of the most desired feature I find people are looking for Jam is how to build shared library. This isn't packed with stock Jam since shared library making is highly platform/OS specific (that is why we have libtool), but in the recent years things are settled up a bit: odd platforms died, wild compilers vanished and there is good chance you will find gcc (or gcc compatible compiler, like clang) on your target platform.

So, here is rule called SharedLibrary you can use with gcc and compatible compilers:

SUFSHARED ?= ".so" ;

rule SharedLibrary {
  local objs = $(>:S=$(SUFOBJ)) ;
  local lib = $(<:S=$(SUFSHARED)) ;

  # compile it
  ObjectCcFlags $(>) : -fPIC ;
  ObjectC++Flags $(>) : -fPIC ;
  Objects $(>) ;

  # link it
  LINKFLAGS on $(lib) = 
     -Wl,-soname,$(lib) -shared [ on $(lib) return $(LINKFLAGS) ] ;
  
  Link $(lib) : $(objs) ;
  Depends all : $(lib) ;
  Clean clean : $(lib) ;
}

Now, calling it with:

SharedLibrary libfoo : file1.c file2.c file3.c file4.cpp ;

will create libfoo.so ready for consumption. In case you are running Windows or other platform where .so extension is not suitable, setting SUFSHARED variable will fix that. The best of all, we completed it in a couple of seconds... ;)

How to shutdown computer under Linux?

You can't!

Maybe this sounds very ignorant, as you will immediately go and try it, or remember the last time you shut down it without problems. Well guys, today shutting down Linux powered desktop is a rocket science...

Let we see how it all started.

In the beginning we had shutdown -h now; people were happy, developers were happy. You knew exactly how it behaved: you (as ordinary user) had to be a super user or user with elevated privileges to call it; developers also had their method: check your id and simply system() that command.

The best of all, this was portable way even between BSD's, Solaris and (presumably) other Unix flavors popular in that time.

But, someone at some point decided this approach is too complicated, so not cool and so stone aged and decided to give ordinary user privileges to put down the computer without asking password. Who was it, I don't know; most likely those guys with idea that mouse and keyboard with a single button are enough for all your problems...

And we got HAL (Hardware Abstraction Layer); resemblance with more famous HAL is probably just coincident, but both had one thing in common: they started as cool thing and ended up as pretty uncool crap.

So, our Linux HAL was also cool: DBus powered, supported all sort of things like receiving events for newly plugged in or off devices, restarting and shutting down computer, giving user privileges and so on.

It was so cool that distros started to ship it and we (users and developers) thought we had a golden egg: no more /proc parsing, no more ask-a-password-to-restart and so on...

But, those guys decided it was (again) too complicated; if you see all sort of things it supported, even on portable way, it was complicated; just they needed time to figure it out. So we got a bunch of *Kit stuff: ConsoleKit, DeviceKit...

If you ever had any touch with API from Apple, you will notice *Kit naming inspiration origin... Doesn't this sounds too biased? Now, if I'm going to add some of LPCTSTR-ed HWORD-like call (MS Windows lowlevel API) over standard Linux calls, people will probably call me nuts because Windows API is a big NO NO; and it happens to be not cool.

Like somene on Slashdot said once: if they like Apple so much, why don't they simple develop apps for it, instead ruining Linux desktop? Sure, they would like it, but Apple would not a give a fuck about their 'cool ideas': those guys are serious and they know you don't wanna fuck with user who pays you a bunch of $$$ for your OS, hardware and devices.

Let we back to our beloved Linux: again, desktop evolved and they decided those *Kit stuff is deprecated (whatever it means today) and we got UPower (for 'power' support and all things they considers had to do with powering your computer), 'policy' and 'console' went to systemd and I'm not sure what crap they think again; but don't be fooled: shutting down or restarting your computer has nothing to do with 'power' so UPower only support suspending and hibernating your PC.

Now, if you are developer and you just want to restart or shutdown your computer, you have 4 (yes four) different way to do it and all depends on distribution: on Fedora you can still use ConsoleKit (although it has systemd); Slackware does not come with systemd and has ConsoleKit by default up, but you have to manualy start UPower, Arch recenly deprecated ConsoleKit in favor of systemd-logind...

Are you getting confused?

But, on other more serious OS-es like FreeBSD, developers don't have time to think about Kits, systemd and all that crap someone came up during toilet session; they are, from Linux developer perspective, stuck on stone age: they are still using HAL.

Sure, those guys are serious and have much better things to do, like improving SMP support, adding support for new hardware, fixing freaking bugs in kernel and userland apps instead of thinking the way how to power of your machine.

One famous Gnome developer said how Linux desktop is dead: yes, guys like him messed things up and flew away saying how nothing could be done... Linux desktop is slowly becoming a corporation led by small number of developers with influence and powerful companies, where even a single damn thing like turning of computer was made so complicated you wish to puke.

Do you know what is the main irony? Solaris, AIX, BSD's in some features are more portable than Linux distros. Go figure out why.

EDE and FLTK talks on FOSDEM

I got a really nice chance to speak about EDE and FLTK on FOSDEM, in two separate talks.

Both talks, EDE related lighting talk and FLTK talk, are scheduled in Sunday; FLTK talk will be held in cross-desktop devroom.

See you there!

Another update

After some period of inactivity here, due various obligations and increased work on EDE, I'm putting a short list of completed changes; some of them are visible and some not.

First the biggest one: a big overhaul of window container inside panel (the place where window icons/buttons are hold). In previous iteration, every window list change, which is emitted by window manager, would trigger buttons cleanup and recreation; not very efficient because this would make many C++ new/delete calls.

Now, those calls were dramatically reduced by tracking window states and desktop position, outside window list received from window manager; this also fixes one bug that annoyed me for some time: when you would focus window by clicking on window titlebar, order of window buttons inside panel would be changed. This is probably pekwm optimization for faster access of top level windows.

The next one is tray icon removal fix: when you had a bunch of apps inside tray and after you did some manipulation with them (close app, reopen and such), tray would leave empty boxes around. No more ;)

jam, a tool for building EDE and edelib, is now bundled with edelib. Beside it is easier to install it on platforms where is not installed (just go to edelib/tools/jam and hit make && make install), it is much easier to fix issues in it and distribute those fixes; you always get updated version with fresh edelib release.

Also, the last but not least, EDE and edelib are updated to compile and work on OpenIndiana, a fork of OpenSolaris. I'm not sure why, but I always get warm feeling around Solaris-es, no matter if they aren't popular much these days.

Upcomming planned changes should be mostly related to EDE Manual transfer to wiki and adding configuration for panel.

Manual is quite incomplete and will be much easier to update it (and contribute with proofreading and fixes) on wiki. Also, this will make code lighter (bundled asciidoc will be removed) making default EDE non dependable on python; however, to build icon theme you will still need it, unless you are using official releases, where theme comes already prepared).

Panel configuration is must feature before 2.1 release because it is often requested feature. Some people would like any kind of configuration and some GUI frontend; I'll see how can be added without delaying release 2-3 months more.

Talk on T-DOSE

I will give a talk about EDE, tomorrow (Sunday), at T-DOSE so feel free to come if you are near by. Also I'll setup booth during conference days (Saturday and Sunday) where you can pick up some EDE related merchandise.

This post is coming a little bit late mainly due preparation and the time spent on trip to Eindhoven. By car ;)

Dash search results

Do you know what is Dash on Ubuntu? I just get it after few search attempts on Google...

The main reason for this post is hilarious comment on Hacker News. Honestly, I'm still amazed (and amused) how they never fixed this thing.

I tried it couple of times; when the first Unity version came, then later after few updates and always would getting the same thing this guy or girl did: nothing ;)

Hello TinyCLOS

A couple of days ago, in edelib tree landed TinyCLOS, a CLOS-like object system for Scheme. I used original implementation and thanks to it's excellent design, I had to change only a couple of lines of code to adapt it.

The main reason for adding it was to stress Scheme interpreter with some serious code so it placed inside edelib test suite and is not installed with the rest of the library.

Truth to be told, I was surprised when TinyCLOS loaded for the first time. Within first runs, I manage to detect a few nasty bugs: two in Scheme functions (append and reverse) and one in interpreter garbage collector. Everything was corner case so ordinary code used by EDE would probably not catch it, but who knows.

Another surprise is startup time: loading TinyCLOS is dog slow and with a couple of tests, it will require almost 10 seconds to complete where around 7-8 seconds will be reserved for library load. That is brutal!

I haven't had enough time to look deeply what the cause is, but one of the reasons could be eager creation of primitive class objects (<class>, <boolean> and so on); the second reason is definitely a large number of GC calls. In both cases things can be improved, which I marked as TODO for upcoming time.

Exploring Desktop Objects #2

In the first part of this text, I explained a couple of reasons why I created edelib-dbus-explorer. In the mean time, this tool got a couple of quite handy features I will try to explain here.

IMHO one of the killer features of Common Lisp, Python or Clojure are docstrings. You write the code and document it at the same time; the documentation becames a part of code, meaning you can easily get it at any point: from REPL or from some GUI fronted.

That is why I added docstring support in edelib-script (based on tinyscheme), so:

(define (foo a b)
  (+ a b))

you can write as:

(defun foo (a b)
  "This is foo function."
  (+ a b))

Yes, it is quite Common Lisp-like, but to avoid messing with interpreter internals and to leave some room for turning off docstring collection in case of optimizations, I put it as defun macro. Maybe I could use different name to reduce confusion, like s7 which uses define*, but I'm not going to bother with that right now.

Now imagine in similar fashion you can document DBus methods or signals. This feature would be extremely useful for tools like edelib-dbus-explorer which, for example, could display method/signal prototype and description as tooltip when user hovers over the name.

Actually this was implemented in edelib-dbus-explorer from the start, but without descriptions, as DBus does not have official way how methods and signals should be documented. However, searching through the various implementations, I noticed EggDBus and GDBus can provide them via annotations. Then I became extremely happy, meaning edelib-dbus-explorer got immediate support for them.

Since both EggDBus and GDBus put docstrings in different namespaces (but ends them with DocString), edelib-dbus-explorer will simply scan for annotations whose names ends with .DocString and pick the value. With this, I don't have to change it when I extend edelib DBus binding to generate introspections with e.g. org.equinoxproject.DBus.DocString annotation name.

Unfortunately, not all (gtk+) applications uses this feature yet, and the worst of all, this will not work with Qt applications. I'm not sure what is official way from Qt/KDE standpoint, but I noticed some of projects are using <tp:docstring> tag inside introspection xml for documentation. I'm not sure even if it is transmitted to DBus server or is stripped when binding tool is creating source code from introspection xml. This needs further investigation.

Beside of this, I added builtin help (you can invoke it by evaluating (help) function) where are described common functions and how is done mapping between DBus and Scheme types. I didn't have enough time to explain it briefly in previous post, so it gets deserved space now.

Tinyscheme (thus edelib-script) is a R5RS based implementation and as most of Scheme implementations have a few object types: string, number, list, vector and some of them hashmaps. Opposite to this, DBus have much richer types and is quite strict about them: if method call expects variable with int32 type, it will refuse to be called with int16 type. Which can be a problem as Scheme does not have notion of 32-bit or 16-bit integers; it only understaind number which is often largest possible integer (sometimes even seen in bignum form).

So I added type hints, inspired from Emacs DBus hints: int16 is represented as :int16, string as :string and so on. All hints must be added to method or signal call arguments if that call requires arguments. For example, dbus-call will call DBus method and using hints it can look like:

(dbus-call "org.foo.baz" "/org/foo/baz" "org.foo.Interface" "Method"
           :string "Some string"
           :uint32 3)

where the first 4 parameters are service name, object path, interface and method. Things gets complicated when we have DBus complex types (like array or struct), but thanks to Scheme/LISP lists, these problems are easy to overcome. So, to represent an array of 4 uint16 types, this is used:

'(:array (:uint16 1 :uint16 2 :uint16 3 :uint16 4))

I know, it is messy, so I cooked a function called dbus-make-array that will simplify this like:

(dbus-make-array :uint16 1 2 3 4)

On other hand, DBus struct type behaves much like C/C++ structs and can have many different types inside own collection, much like Scheme lists. Unfortunately, you still needs to explicitly add types, like:

'(:struct (:uint16 1
           :string "Foo"
           :object-path "/org/baz"))

Dictionaries are list of lists, where the first element is key and the second is value; both again must have types:

'(:dict (:string "key1" :bool 1)
        (:string "key2" :bool 0))

And any of these can be a part of each other, creating even more complex combinations. Truth to be told, from syntax stand of point, things can be improved, but it is all matter of creating additional functions or macros. For example, we can simplify struct syntax like:

(make-struct :uint16 1
             :string "Foo"
             :object-path "/org/baz")

I didn't cover other supported types, like Variant or ObjectPath and I'm leaving documentations to do that. However, one thing I would like to mention is the plan to add support for implicit conversion; for example, all positive Scheme numbers could be uint32 type and the negative int32. This would make typing and overall things much easier.

Anyway, since video speaks more than thousand images, here is a small demo of the main edelib-dbus-explorer features in usage. If you would like to get hands on it, you will need to download edelib svn source code and compile it.

Feel free to ping me if you find some issues :)

Taskbar Icons Fix

When the new taskbar applet landed in ede-panel, application icons were fetched in pretty standard way: inspect _NET_WM_ICON hint and decode image data, if application set it.

However, I overlooked one major feature of mentioned _NET_WM_ICON: this hint can support multiple icons (by different sizes), and modern GUI applications are starting to use it extensively. I added support for this in one of recent commits.

What are benefits of this? First of all, take a look at the provided picture:

The first image is natural sized (16x16) provided by application and the second one is explicitly scaled, which was done until now. So beside cleaner icon look, we saved a couple of CPU cycles that would be wasted for unneeded scaling.

Exploring Desktop Objects #1

Recently I played a little bit with Pharo (which is a fork of Squeak Smalltalk) and I was quite impressed with it. Since this was my first connection with Smalltalk, the language simplicity and clarity struck me hard, wondering why we are still living in dark ages of C++/Java or whatever language that is daring to call itself Object Oriented.

A perfect companion for this language comes in form of it's own environment: you have a full desktop under single executable which isn't desktop in a normal sense: it is much more like environment of objects, where everything you touch and move (window, button) is a true object.

Of course, every sane GUI C++ program will use object notation for buttons or windows, but at the end, they are compiled down to assembly and you are done with it. To have a false sense of ability to change it, you would modify some configuration files, reread them and load the program again.

With Smalltalk is different: if you want to change how button looks in certain window, you just get it's object and call whatever method you can call (in Smalltalk parlance: you send a message). Or, if you, at some point would like to see how this window is written, you simply query it's source code.

If you are still not convinced, check these videos from Alan Kay's Etech Presentation. Remember that was 2003 and we still can't do many of those things with (insert your favorite language here), no matter how fancy it is.

But, this article is not about how Smalltalk is glorious but what can be done to improve current situation. And some things can be done indeed, even if we are still living in stone age of modern languages (sic).

Now lets go to the matter.

Today modern way to communicate between desktop components and applications is DBus so situation here is very much status quo. DBus became stable, everyone use it and everyone is happy.

DBus brings notation of object paths, interfaces and methods; you can see object paths as instances living in certain namespace, which is pretty neat since you will have a lot objects floating around.

So DBus is very much object oriented, but why we are still have stone age tools to handle it? I'm not counting here language bindings (where btw. some of them are awesome), but the tools for exploring current objects (or object paths) and their context. Let we see what we have:

• standard tools shipped with dbus (dbus-monitor and dbus-send): well unless you know how to manually encode the message with array of strings or, for God sake, struct of arrays and dictionaries, you have to look somewhere else
• qdbusviewer and qdbus: much better, comes with Qt. Even qdbusviewer will popup a dialog to fill method arguments when you are going to call that method. However, services which do not have introspection data will make it unresponsive (you will need to restart it). Setting complex parameters (like arrays or dictionaries) is not possible.
• DBus Explorer: never tried it, but C#/Mono background decided for me to never try it; I don't have mono installed and not planning to do so.

How about some tool with exploring ability and ability to write and call custom code from the same place? Or maybe to have some IDE capabilities like generating code or displaying documentation of selected methods? Unless you are going to write it, there isn't one.

Why this matters when we have nice language bindings and even better archaic tools like dbus-send?

Well, let suppose you are going to write a client for PackageKit, but your language doesn't have ability to integrate packagekit-glib2 (or it was packagekit-glib :P) or simply, you don't want to add another library as dependency?

In that case, the only solution is to read reference api where you will get lost in a matter of seconds. Who needs examples when all methods are nicely documented and colored. What to call in which order? Well, either read the code or use dbus-monitor.

With the same approach applied above, if you are going to write your console http client (for example), you would either have to consult firefox source code or use wireshark to decipher http protocol. C'mon people, we are not living in '90-ties any more; we are lazy today and we prefer to see examples first.

Or, let put PackageKit aside (as we don't write package management tools every day). How about to see what (DBus) services we have on our system, which interfaces and objects they exposes? Or simply, your program exposes services; how the hell you are going to test it? Again, you will use either dbus-send or write some testing code with python/ruby/etc. (before that make sure to download all their dependencies as their developers like to depend on as much libraries as possible).

So to make situation in this field less painful as possible, the last couple of days I was working on edelib-dbus-explorer (it comes with edelib from svn). With it, I was trying to address above issues that itched me for some time.

edelib-dbus-explorer (as you can see from the shot) looks much like qdbusviewer, in layout form, but adds scheme interpreter as the main communication point (or better say edelib-script, which is nicely packaged tinyscheme with a bunch of addons).

In a Smalltalk fashion, you explore services and objects, find some method and hit 'Send to editor': you will get a code snippet ready for evaluation. Then, you continue to write some more code, add another method call and at the end, save everything. Could it be more complicated?

edelib-dbus-explorer recognizes almost all DBus types (except signatures and file descriptors); return values will be converted to scheme objects (simple types to corresponding scheme values, like DBUS_STRING to string and complex to lists, or list of lists like dictionaries). For input types (those that serves as arguments to method calls), explicit type designation must be appended as DBus is picky if you use uint32 or int16 because signature is different.

But, explicit typing is not an issue: when is instructed to generate code, all types will be correctly placed with added REPLACE_ME placeholder, which must be replaced with appropriate values. Hitting Shift-TAB will jump between those placeholders.

Is this better than previous solutions? I'm confident it is and can be even better, which adds more room for improvements.

to be continued...

Hello notifications

During these slow preparations for 2.0 release, I figure out how EDE does not have any kind of notification service, where applications could report custom statuses.

I'm using Fedora Xfce Spin, where I replaced Xfce with EDE and recently I removed all Xfce applications and libraries from the system. This affected Xfce custom notification daemon which displayed various infos (e.g. firefox download status, VirtualBox driver update and such). AFAIK, more and more apps are using this notification specification which is good.

So here it is, with humble name: ede-notify-daemon. It support important parts of the spec, where the rest I will leave for upcoming versions. Truth to be told, I will (probably) never implemented full specification as it badly complicate simple thing as displaying notifications. I'm wondering are those GNOME/KDE guys come up with anything simple or we will at the end start to roll (again) own solutions?

There is no configuration options for ede-notify-daemon; this is planned to be done in 2.1 release.

Small panel enhacements

With last couple of commits, panel got two small enhancements: variable width and hiding capability.

Setting custom panel width was feature requested long time ago for eworkpanel in EDE 1.x. I'm not sure why but people likes it, although I'm getting feeling something is missing when I'm not having fully stretched panel. But, we should not discuss about personal preferences...

As everybody likes screenshots, here it is:

Check the gallery for full size, as I wasn't able to find sane way to link smaller thumbnails on bigger images.

The background is taken from Desomnis gallery; she kindly allowed me to to use couple of images as wallpapers and distribute them with EDE package. Nice example in murky art world, where IMHO they are quite behind with their licenses (comparing to GPL, BSD, etc.) and do-not-use-until-I-allow-it attitude.

The second enhancement is addition of small button (I called it hider) for explicit panel hiding. I always liked this feature in older KDE/GNOME versions, which sadly gone over the time. Autohide is nice feature (which by the way is not implemented yet), but I find it more annoying than usable: panel is hidden, you accidentally move mouse to the bottom and it pops out, then wait to hide itself again... I like more explicit things: when I hide it, let it stay hidden until I decide to show it.

Again, personal preferences...

Just to note: there are issue when panel width is shrinked and clicked on hider; panel will not be able to be shown any more. This will be hopefully fixed soon.

Screen locking support

Well, I'm pleased to announce two, small, but excited news: my ssh account for equinox-project.org was restored (yea!) and screen locking support was added.

Screen locker is actually a small shell wrapper (called ede-screen-lock) around xscreensaver and/or xlock and will choose one, depending on whether or not is one of them installed. If you have another locker you consider is more popular (I'm a bit behind recent changes in desktop world), please drop me a note.

Why I'm so excited around this small addon? Well, it is the first (user visible) change after more than a half year. In the mean time, I did a lot of changes in backend code, mostly related to new scheme dialect called edelib-script (used in still experimental theme engine) I will write more about it in one of upcoming posts.

The next major todo is to focus on updating and refreshing EDE web page and starting wiki server. Also to mention, I created and setup alternative domain, http://edeproject.org, which will point you back to http://equinox-project.org; edeproject.org seems to me much shorter and leaner, but equinox-project.org is what we get used to, so it will be here for long time.

Bad bad vim

New post after so long of inactivity. And negatively oriented, toward bashing my favorite editor: vim.

I'm not sure why people are calling emacs a kitchen sink of editors when vim is on a good path to became, even a bigger one.

From time to time I fire up emacs (recently a little bit more often than before after I discovered Evil, vim uber emulation mode for emacs, making emacs usable to us, poor vi/vim users) to see what progress is made in editor world and how vim is keeping up with it.

Sometimes I am happy why I'm still using vim (speed, integrated spell check) and sometimes I'm jealous for some features vim probably will never have (external processes inside editor, dbus support, extension language) or are implemented badly (syntax coloring, extension language, own spell check instead already existing, like aspell, ispell or else).


Well, see, for emacs we have Babel and I'm very happy with it. Install emacs and install Babel and things works.

Vim has also nice one, called VimTranslator, except it supports only Google Translate. This is not an issue, except you have to have installed ruby to use it.

No matter I'm not using ruby at all, to use full vim version I must install ruby. Probably because to write vim extensions you can use 10 different languages, forcing your users to install them and everything those languages requires. Yuck!

Emacs is not perfect either, but to extend it I need to learn single language (elisp) and I can be productive. For vim, I can choose between half baked junk called vimscript or something better in form of heavyweight alternatives like python, perl, ruby... What to expect in the future; java maybe?