Tuesday, April 10, 2012

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:

Panel shot

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.

Hider shot

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.

Monday, April 2, 2012

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.

Thursday, February 9, 2012

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?