GTK-based applications #1: Terminal emulators (2/3)

Here’s the second part of the GTK terminal emulators test. It’s N – Z today. Again we have 9 terminal emulators to take a look at.

The candidates

Here are the candidates:

(Again: Since there’s a lot of them out there, I may well have missed some interesting ones. Feel free to tell me in this case!)

Not tested

Last time I forgot to mention 3 more terminal emulators which don’t run on my test system:

(If you happen to get any of these to work on Arch and care to tell me, I’d be happy for any comments.)

Testing system

The testing system was the same that I described in my previous post.

QuTerm

QuTerm is a Quake-style terminal emulator which uses GTK2.

LXDE with QuTerm

Installation

pacman -U quterm-0.1-1-i686.pkg.tar.xz (4868 / 5 KB)

Statistics

Memory usage after starting up LXDE and opening QuTerm via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux LXDE QuTerm 0.1
MemTotal: 3625888 kb
MemFree: 3514496 kb
Buffers: 10508 kb
Cached: 61876 kb
Rootfs: 830984 / 812 MB
RAM used at startup: 111392 / ~109 MB
Disk space (less LXDE system): 13504 / ~13 MB

ROXTerm

ROXTerm is a terminal emulator which uses GTK3.

LXDE with ROXTerm

Installation

pacman -S roxterm (230084 / 230 KB + 13 dependencies: 14899200 / 14,9 MB)

Statistics

Memory usage after starting up LXDE and opening ROXTerm via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux LXDE ROXTerm 2.7.2
MemTotal: 3625888 kb
MemFree: 3506020 kb
Buffers: 10552 kb
Cached: 68612 kb
Rootfs: 933296 / 912 MB
RAM used at startup: 119868 / ~117 MB
Disk space (less LXDE system): 115816 / ~113 MB

Sakura

Sakura is a terminal emulator which uses GTK3.

LXDE with Sakura

Installation

pacman -S sakura (40416 / 40 KB + 12 deps: 14899200 / 14,9 MB)

Statistics

Memory usage after starting up LXDE and opening Sakura via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux LXDE Sakura 3.0.4
MemTotal: 3625888 kb
MemFree: 3508796 kb
Buffers: 10204 kb
Cached: 68288 kb
Rootfs: 929500 / 908 MB
RAM used at startup: 117092 / ~114 MB
Disk space (less LXDE system): 112020 / ~109 MB

Stjerm

Stjerm is a Quake-style terminal emulator which uses GTK2.

LXDE with Stjerm

Installation

pacman -U stjerm-git-0.16_19_g4038b07-1-i686.pkg.tar.xz (19564 / 20 KB)

Statistics

Memory usage after starting up LXDE and opening Stjerm via run (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux LXDE Stjerm 0.16_19
MemTotal: 3625888 kb
MemFree: 3515092 kb
Buffers: 10552 kb
Cached: 61552 kb
Rootfs: 829620 / 811 MB
RAM used at startup: 110796 / ~108 MB
Disk space (less LXDE system): 12140 / ~12 MB

Termite

Termite is a terminal emulator which uses GTK3.

LXDE with Termite

Installation

pacman -U vte3-select-text-0.34.6-1-i686.pkg.tar.xz (356904 / 357 KB 12 dep: 14899200 / 14,9 MB)
pacman -U termite-6-1-i686.pkg.tar.xz (19520 / 20 KB)

Statistics

Memory usage after starting up LXDE and opening Termite via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux LXDE Termite 6
MemTotal: 3625888 kb
MemFree: 3510272 kb
Buffers: 10220 kb
Cached: 67108 kb
Rootfs: 931076 / 910 MB
RAM used at startup: 115616 / ~113 MB
Disk space (less LXDE system): 113596 / ~111 MB

Tilda

Tilda is Quake-style a terminal emulator which uses GTK2.

LXDE with Tilda

Installation

pacman -U tilda-git-20130625-2-i686.pkg.tar.xz (64824 / 65 KB + 2 deps: 133120 / 133 KB)

Statistics

Memory usage after starting up LXDE and opening Tilda via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux LXDE Tilda git-20130625
MemTotal: 3625888 kb
MemFree: 3516252 kb
Buffers: 9800 kb
Cached: 62824 kb
Rootfs: 830976 / 812 MB
RAM used at startup: 109636 / ~107 MB
Disk space (less LXDE system): 13496 / ~13 MB

Tinyterm

Tinyterm is a terminal emulator which uses GTK2.

LXDE with Tinyterm

Installation

pacman -U tinyterm-svn-20100223-1-i686.pkg.tar.xz (4180 / 4 KB)

Statistics

Memory usage after starting up LXDE and opening Tinyterm via run (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux LXDE Tinyterm svn-20100223
MemTotal: 3625888 kb
MemFree: 3514148 kb
Buffers: 10520 kb
Cached: 62804 kb
Rootfs: 829576 / 811 MB
RAM used at startup: 111740 / ~109 MB
Disk space (less LXDE system): 12096 / ~12 MB

vTerminal

vTerminal is a terminal emulator which uses GTK2.

LXDE with vTerminal

Installation

pacman -U vterminal-13-3-i686.pkg.tar.xz (11988 / 12 KB + 2 deps: 40960 / 41 KB)

Statistics

Memory usage after starting up LXDE and opening vTerminal via run (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux LXDE vTerminal 13
MemTotal: 3625888 kb
MemFree: 3510000 kb
Buffers: 12940 kb
Cached: 62480 kb
Rootfs: 831176 / 812 MB
RAM used at startup: 115888 / ~113 MB
Disk space (less LXDE system): 13696 / ~13 MB

Xfce4-Terminal

Xfce4-Terminal is a terminal emulator which uses GTK2.

LXDE with Xfce4-Terminal

Installation

pacman -S xfce4-terminal (300188 / 300 KB + 4 deps: 399360 / 399 KB)

Statistics

Memory usage after starting up LXDE and opening Xfce4-Terminal via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux LXDE Xfce4-Term 0.6.2
MemTotal: 3625888 kb
MemFree: 3505716 kb
Buffers: 11160 kb
Cached: 63488 kb
Rootfs: 835304 / 816 MB
RAM used at startup: 120172 / ~117 MB
Disk space (less LXDE system): 17824 / ~17 MB

What’s next?

The next post will be a summary of the GTK terminal tests and provide a table for easy comparison.

[Update (08/10): Corrected Termite’s disk usage values – copied the wrong ones before.]

GTK-based applications #1: Terminal emulators (1/3)

Today we’re in for taking a look at the various terminal emulators out there which are based on GTK+. This first part deals with the ones which start with A to M.

The candidates

Here’s the list of available GTK+ terminals I got working on Arch:

(Since there’s a lot of them out there, I may well have missed some interesting ones. Feel free to tell me in this case!)

Not tested

Here’s the list of GTK-based terminal emulators which I didn’t test because they didn’t work (since there are so many available I didn’t have much time to mess with these here):

(If you happen to get any of these to work on Arch and care to tell me, I’d be happy for any comments.)

Testing system

For the coming tests I set up a new, clean Arch VM (25.06.2013). The basic system looks like this (after cleaning pacman cache):

Arch Linux “base”
MemTotal: 3625888 kb
MemFree: 3586228 kb
Buffers: 5404 kb
Cached: 18556 kb
Rootfs: 488660 / 478 MB
RAM used at startup: 39660 / ~39 MB

Then I installed a typical LXDE:

pacman -S xorg-server xorg-xinit xf86-video-vesa lxde (132 packages; size: 59914 Bytes / 59 MB)

Memory usage right after starting up LXDE (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux + LXDE (0.5.5)
MemTotal: 3625888 kb
MemFree: 3522368 kb
Buffers: 9740 kb
Cached: 58860 kb
Rootfs: 817480 / 799 MB
RAM used at startup: 103520 / ~101 MB
Disk space (less basic system): 328820 / ~321 MB

Dwt

DWT is a terminal emulator which uses GTK3.

LXDE with dwt

Installation

pacman -U dwt-0.3-1-i686.pkg.tar.xz (7272 / 7 KB + 19 dependencies: 1689000 KB / 17 MB)

Statistics

Memory usage after starting up LXDE and opening Dwt via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux LXDE dwt 0.3
MemTotal: 3625888 kb
MemFree: 3502520 kb
Buffers: 11648 kb
Cached: 67740 kb
Rootfs: 958252 / 936 MB
RAM used at startup: 123368 / ~120 MB
Disk space (less LXDE system): 140772 / ~137 MB

Evilvte

Evilvte is a terminal emulator which uses GTK3.

LXDE with Evilvte

Installation

pacman -U evilvte-0.5.1-1-i686.pkg.tar.xz (28244 / 28 KB + 13 deps: 14899200 / 15 M)

Statistics

Memory usage after starting up LXDE and opening Evilvte via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux LXDE Evilvte 0.5.1
MemTotal: 3625888 kb
MemFree: 3508236 kb
Buffers: 10292 kb
Cached: 68140 kb
Rootfs: 923508 / 902 MB
RAM used at startup: 117652 / ~115 MB
Disk space (less LXDE system): 106028 / ~104 MB

Ftjerm

Ftjerm is a terminal emulator which uses GTK2.

LXDE with Ftjerm

Installation

pacman -U ftjerm-0.12.3-1-i686.pkg.tar.xz (24968 / 25 KB)

Statistics

Memory usage after starting up LXDE and opening Ftjerm via run from the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux LXDE Ftjerm 0.12.3
MemTotal: 3625888 kb
MemFree: 3514480 kb
Buffers: 10556 kb
Cached: 62180 kb
Rootfs: 822280 / 804 MB
RAM used at startup: 111408 / ~109 MB
Disk space (less LXDE system): 4800 / ~4.6 MB

Gnome-terminal

The gnome-terminal is a terminal emulator which uses GTK3.

LXDE with Gnome-terminal

Installation

pacman -S gnome-terminal (16056320 / 16 MB)

Statistics

Memory usage after starting up LXDE and opening Gnome-terminal via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux LXDE Gnome-terminal 3.8.3
MemTotal: 3625888 kb
MemFree: 3501640 kb
Buffers: 12000 kb
Cached: 69792 kb
Rootfs: 931004 / 910 MB
RAM used at startup: 124248 / ~121 MB
Disk space (less LXDE system): 113524 / ~111 MB

Lilyterm

Lilyterm is a terminal emulator which uses GTK2.

LXDE with Lilyterm

Installation

pacman -S lilyterm (163840 / 160 KB)

Statistics

Memory usage after starting up LXDE and opening Lilyterm via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux LXDE Lilyterm 0.9.9.2
MemTotal: 3625888 kb
MemFree: 3516284 kb
Buffers: 9748 kb
Cached: 62648 kb
Rootfs: 822928 / 804 MB
RAM used at startup: 109604 / ~107 MB
Disk space (less LXDE system): 5448 / ~5.3 MB

Lwt

Lwt is a terminal emulator which uses GTK2.

LXDE with Lwt

Installation

pacman -S lwt-20130625-1-i686.pkg.tar.xz (4380 / 4 KB)

Statistics

Memory usage after starting up LXDE and opening Lwt via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux LXDE Lwt 20130625
MemTotal: 3625888 kb
MemFree: 3517248 kb
Buffers: 9776 kb
Cached: 62272 kb
Rootfs: 822204 / 803 MB
RAM used at startup: 108640 / ~106 MB
Disk space (less LXDE system): 4724 / ~4.6 MB

Lxterminal

Lxterminal is a terminal emulator which uses GTK2.

LXDE with Lxterminal

Installation

Included with LXDE

Statistics

Memory usage after starting up LXDE and opening Lxterminal via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux LXDE Lxterminal 0.1.11
MemTotal: 3625888 kb
MemFree: 3515556 kb
Buffers: 9728 kb
Cached: 62020 kb
Rootfs: same as LXDE
RAM used at startup: 110332 / ~108 MB

Mlterm

Mlterm is a terminal emulator which uses GTK3.

LXDE with Mlterm

Installation

pacman -U mlterm-3.2.0-1-i686.pkg.tar.xz (622240 / 622 KB + 19 deps: 16404480 / 16 MB)

Statistics

Memory usage after starting up LXDE and opening Mlterm via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux LXDE Mlterm 3.2.0
MemTotal: 3625888 kb
MemFree: 3517600 kb
Buffers: 10120 kb
Cached: 61444 kb
Rootfs: 935600 / 914 MB
RAM used at startup: 108288 / ~106 MB
Disk space (less LXDE system): 118120 / ~115 MB

Mt

Mt is a terminal emulator which uses GTK2.

LXDE with Mt

Installation

pacman -U mt-.1-2-i686.pkg.tar.xz (4260 / 4 KB)

Statistics

Memory usage after starting up LXDE and opening Mt via run from the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux LXDE Mt .1
MemTotal: 3625888 kb
MemFree: 3515324 kb
Buffers: 10504 kb
Cached: 61212 kb
Rootfs: 825676 / 807 MB
RAM used at startup: 110564 / ~108 MB
Disk space (less LXDE system): 8196 / ~8.0 MB

What’s next?

The next post will deal with the rest of the GTK+ terminal emulators which I got running.

An interview with the EDE developer

It’s summer solstice today and thus the longest day of the year. I promised something special and here it is: Sanel Zukan, the man behind the Equinox Desktop Environment (EDE) agreed to give me an interview (or to answer a few questions if you will).

If you’re not familiar with EDE, I tried to summarize it up for you before the interview.

EDE in short

What is EDE? It is a full DE you might not even have heard of despite it being one of the older *nix desktop environments. Of course it’s older than Unity, MATE, Razor-qt and the likes. But it is also older than LXDE and – hard to believe – E17! At the same time it’s more light-weight than any of these – including the ones which were created as light-weight alternatives themselves.

Said DE is something special. Where others talk about being light-weight, EDE seriously means it and takes the gloves off. Not making any compromise, it’s the only full DE which is based on FLTK (Fast Light Toolkit), a GUI toolkit which also lives up to its name.

Not being packaged by any major distribution, today EDE is mainly used on older pcs or other systems which are low on resources. It doesn’t provide its own applications for everything nor does it want to. Driven forward more or less by one lone fighter, it surely doesn’t have to hide and fear comparison with other DEs. Taunted as “poor man’s KDE” by some and appreciated as an insider’s tip without all the knick-knack by others it’s just going its way. And if it rightfully deserves one label that would be “No bloat here”. Seriously.

Interview with Sanel Zukan

The following interview was conducted by email.

Please introduce yourself first: Who are you, how old are you and where are you from?

I’m 32, from Sarajevo. By day I’m doing java/python stuff for a small local company and by night I try to hack various OSS projects; of course EDE, too.

Do you have any special interests aside the IT sector you would like to mention here?

Martial arts! πŸ™‚ It is quite challenging to combine IT work with regular training …

For how long have you been using Linux?

Let’s see… For approximately 10 years.

Which is your distribution of choice and why?

Slackware. Because it is simple, lean and very, very stable. I really admire Patrick (Slackware author and maintainer) because he is showing us how a complex project can be and should be maintained.

Is there anything in the Linux or FOSS world you are not really happy with?

The idea to reinvent the wheel all over again. PulseAudio, systemd, gdbus, kdbus, *Kit, are some examples. Instead of improving the current state, those guys focus on rewriting it, making another set of mistakes which brings the full idea back to the beginning: a half balked product.

Also this is quite hard to follow from a developer’s perspective because APIs are changing often; no wonder that developers are going to OS X or *BSD land. This whole way of thinking makes Linux look bad, especially from a novice user’s perspective.

There are more than 15 desktop environments in use in the Linux world. Why did you decide to dedicate your time to EDE?

I like fast, simple and responsive environments without much of bloat that don’t get in your way. Desktops should be invisible and the user should be able to focus on daily tasks more than on desktop effects.

And I like to revive old computers: they are still usable for daily tasks so why to throw them away? Now, the last thing on those computers you want is a desktop that eats all of your memory or cpu power.

What can you tell us about early EDE?

Not much because I’m not familiar with its early history. When I came in, the project was pretty much dead and all original developers had left it. Not sure about the reasons because I never got any reply from them.

What do you think were the most remarkable achievements of versions 1.x?

The project gained some traction and people started to talk about it. One of the reasons for this were regular releases (5-6 months).

Most developers retired from working on EDE. Can you tell us the reason for that? Was it due to technical problems? Real-life issues? Or perhaps the fact that EDE never became popular and remained an underdog to this day?

Maybe a little bit of everything. Working on a desktop isn’t an easy task because there are a lot of pieces involved in it: UI development, low-level stuff, application incompatibilities, etc. Also, doing it in your free time requires dedication.

Do you still have contact with the retired devs and do you know if they still care for EDE (though not actively participating)?

Only with Vedran. Others (except Dejan) never bothered to even reply to my mails.

You took over EDE – and managed to rebuild the DE from scratch with version 2.0. Why did you continue to work on it and did anybody help you? Where did you draw your motivation from?

Sure, there are a lot of people who come and go, give some ideas, fix issues; this project would not be alive without their help that’s for sure. Why do I continue to work on it? Because there is no desktop that satisfies my needs: be simple and stable. And it is fun.

“eFLTK” – can you tell us what that was and why it was created?

eFLTK was a fork of the never-released FLTK 2.0 and it was created with the idea to speed up FLTK 2.0 development and make desktop development easier.

FLTK, following true UNIX philosophy, is a GUI only toolkit and you need much more for a functional desktop environment. That is the main reason I still prefer FLTK over other popular GUI libraries; I’m paying only for what I use.

This modified toolkit was one of the main reasons to start over with 2.0, right?

Yes. Maintaining a desktop and a complex toolkit (eFLTK got a tons of new stuff) isn’t an easy task so we decided to drop it and go on using something with much better support.

Why are you using FLTK? Why not for example FOX (which has its own desktop project that however seems to go nowhere)?

Probably by accident. πŸ™‚ When I started to use and develop for Linux, I didn’t have much experience with UI development, so I searched for something that is easy to pick up, small enough to grasp and have good OpenGL support.

I needed OpenGL because, in that time, I tried to build some level design tool for my pet game.

According to their site, LXDE considered using FLTK as well. In the end it was rejected in favour of GTK+ because it offered too little internationalization support. What about EDE in this regard?

One of the main reasons why we pushed eFLTK for so long is because FLTK 1.1.x, in that time, didn’t have UTF-8 support, which is probably the reason why the LXDE guys ditched it.

Do you use EDE on a daily basis? What other DEs do you like?

Yes. I’m using it on all my computers, including on work; that is why I’m focused on stability so much. It is not good idea to lose all of your daily work because of a bug in the WM or panel.

Other DEs I like? I like Γ‰toilΓ© (http://etoileos.com) because they are doing some really cool stuff; I’m not sure what the current status is because the project looks dead to me, which is quite sad.

Those who followed the development of EDE mostly thought that the project was dead when all of a sudden 2.0 final was released. What had happened?

We (Vedran and I) went silent to focus on 2.0 development and release it as soon as possible. It took some time because there was a lot of work to do, and we did it twice!

To explain this, I need to tell some of FLTK’s history which greatly affected EDE. FLTK project had two main branches, stable 1.1.x and 2.0.

FLTK 2.0 promised a lot of new and shiny things, like namespace support, UTF-8, advanced X stuff (RandR, Render and etc.). EDE initially started to use FLTK 2.0 (even before I joined) which was forked at some point and eFLTK created.

After some talk with the FLTK 2.0 devs, they promised us to make a release soon; we ditched eFLTK, started to rewrite EDE in FLTK 2.0 and started to contribute to that toolkit.

Unfortunately that library (as if it was cursed) never got released. I got really mad and rewrote everything (with Vedran’s help) again in FLTK 1.1.x and never regretted it. This should have been done long time ago.

Are you happy with 2.0 in general?

Pretty much.

What about EDE users – do you get a lot of feedback? Are there any features which are often asked for?

Yes; I’m getting more feedback by mail than on the EDE forum, which isn’t good as people new to the project tend to think it is inactive. However, I understand why people sent me the mails: SourceForge forums are extremely bad and they get a reply much faster. πŸ™‚

Main features asked for are more configuration support, a file manager and support for internationalization. Funny thing: no one ever asked for compositing or blinky blinky stuff.

EDE 2.1 is on its way and might be available soon. What new features can EDE users expect from it?

More stability, more speed and tons of little improvements including full panel configuration.

Let’s talk about the future. What are your plans for EDE after 2.1? What is your “goal” with EDE?

Truth to be told, after the 2.0 rewrite I learned not to do any big changes anymore but small incremental ones instead. So after 2.1 I’m planning to add a File Manager, fix remaining bugs and add more DBus support.

Ultimate goal? I really like and admire Smalltalk environments (like Pharo) where you can change, adapt or remove programmatically any part of it. I would like to add some of those things in EDE but it will be quite challenging, because Pharo is powered by Smalltalk and EDE is done in C++ which isn’t suited for runtime dynamism. That is why I added a Scheme interpreter and plan to use it more often in the future.

A little statistics: How many daily hits does the project homepage currently have in average?

Huh not sure; the last time I checked EDE had ~5000 hits per hour; now if half of that are bots, the stats aren’t bad considering the last release was a year ago and the project isn’t mentioned much in the media.

However, there are very big peeks each time a new version is released.

What do you think are the reasons for EDE to be still quite unknown among Linux users despite existing for more than 10 years? How to change this fact?

Probably a few things:

1) lack of frequent, predictable releases
2) more advertizing
3) support from a big company

If you remember, LXDE gained wide traction when RedHat created a Fedora spin for LXDE.

There’s also the FLTK applications project – but it hasn’t really released anything, yet. Do you know anything about that or about any FLTK applications in the making?

Not much. It was probably some attempt to document and collect popular applications, but never got significant traction. Probably one of the reasons is that more people develop commercial applications with FLTK, because it still has a quite liberal license.

You awake at night, a strange light surrounding you. The good FOSS fairy is floating in the air before you! She can do absolutely everything FOSS related; whether it’s doxygen with zero dependencies, FLTK 2 revived and actively developed or something a little less unlikely. πŸ˜‰ She grants you three wishes!

LOL. Well:

1) Live kernel update
2) File system with good snapshot and history support (like ZFS)
3) Webkit with FLTK backend

Ok, back to serious. A coder with some time on his hands is searching for a new project. He stumbles over EDE and likes it. If he asked you how he could help with it what would you advice him to do?

He could try to fix things he don’t like or create applications he would like to see. I’m always open to ideas and ready to give some guidance.

Which FLTK application that was never made do you miss the most?

Webkit with an FLTK backend. There was some project a long time ago including even a screenshot, but author never made any code public.

Why was EDE’s own WM replaced with PekWM? What are your plans for the future of the WM used in EDE?

To speed up the release. Developing a WM from the scrach, or porting it to another toolkit, is quite time-consuming so I used pekwm as temporal replacement. There are plans to replace it, but I’m not thinking about it right now, because there are more important things to be done, like the file manager.

Thanks a lot for taking the time to answer these questions – and of course for EDE! I wish you success with your further work on it.

What’s next?

My next blog entry will be about EERIE turning 1 year old and about what has been accomplished so far.

Situation of the Linux Desktop #2: Habemus tumultum…

… qui nomen nominatur “pacem”!

Wow, Latin! Oh er, welcome back! Wonder what that strange sentence does there – and what it may have to do with the Linux Desktop? Well, due to unforeseeable incidents when moving houses along with some family matters, I was more or less cut off from any news. I didn’t have internet connection for about one month and was not in the mood to buy a newspaper (and since TV and radio programs are more or less useless to disgusting and a total waste of time, I don’t own a TV or a radio). You can probably imagine how surprised and amazed I was yesterday when I finally read what had happened in the meantime!

The news of not even a handful of weeks missed – and all of a sudden the Roman Catholic church has a new pope (even though the old one didn’t die!). That was what inspired my headline which translates (or at least should translate) to: “We have a turmoil… which is called (the name) peace!”

“ΠœΠΈΡ€”

“Peace”?! Yes, peace. It’s one possible translation of the Russian word in the sub-headline above. Others are “world” or even “universe”, but I couldn’t resist to put together peace and turmoil. πŸ˜‰ What the heck am I talking about? Alright, alright. You’ll know what I mean right away. “ΠœΠΈΡ€” is pronounced… Mir!

Well, Mir! You’ve probably heard of the new display server which Canonical (makers of Ubuntu) announced. Even this announcement had a huge impact in the Linux world. A lot has already been written about it. But this is one topic that clearly affects the subject of my blog – the Linux Desktop. While I tried not to be too biased about Ubuntu in the past, Canonical are giving me a hard time once again.

Closed graphic drivers

My position on the efforts of Canonical, Valve and others was one of cautious confidence that it could be of great value to the Linux community. I’m not one of those Linux fans who want this operating system to “succeed” and I don’t really care for market shares and things like that. But there’s certainly some truth to the fact that we’d all benefit from good drivers provided by the companies who build the hardware. Yes, while I prefer open drivers (for obvious reasons), I don’t have a problem with closed drivers being available, too. It’s one additional option for those who need the performance, reliability, etc.

It’s common knowledge that X11 is really old now and that this is not just beginning to show. For the conservative desktop environment X will remain the display server of choice but the general next step, the future of the modern Linux Desktop would be Wayland. Almost everybody agreed with that – at least until early march. A few years ago even Canonical had praised Wayland and planed migrating to it in the future. Now said Company is developing their own display server Mir…

Canonical’s Mir and Wayland

Alright, Canonical have abandoned the classic desktop with Unity and are clearly aiming for the mobile market. That’s ok, I guess. But developing a new display server and convincing Nvidia (who already hesitated to support Wayland!) to support it instead of Wayland is not a nice move at all. Doing so at this particular time (before Wayland could actually play any role) really looks like an attempt at backstabbing that other display server for me!

Thanks to Canonical, Nvidia will be even less motivated to offer drivers compatible with Wayland. Canonical’s founder even boasted of Mir possibly running on more devices than Wayland! That sounds like a plan. A plan that may be very profitable for Canonical but also a plan that can prove to be devastating for the Linux community. How to treat the new situation? Curse and boycott Mir? That’s probably overreacting. Embrace and praise Mir? Certainly not at this time. Anyway all this is a development that we should eye closely. Perhaps Mir will provide a few interesting features in the future. Right now it’s just a concept – and a splitting one. Let’s see what happens next.

GNOME 3 and Consorts

Another thing has happened since I wrote the first “Situation of the Linux desktop” in November. MATE is no longer the only promising GNOME fork. Now there’s also Consort.

The difference between them is that MATE picked up the dead GNOME 2 and remains based on the GTK+2 toolkit. According to the makers of Consort, this is “dead technology” and their effort is maintaining a classic GNOME desktop based on GTK+3. GNOME 3 will be dropping their “GNOME classic” or “fallback” mode with the upcoming version 3.8. This mode resembles GNOME 2 in many ways – but the most important thing for many people is the fact that it does not require hardware graphics acceleration. So Consort will be picking up where GNOME 3 Classic left.

Currently Consort doesn’t work with Arch Linux so I didn’t test it, yet. So I can’t say much more about it right now.

The situation!

The Linux Desktop has fragmented even more since my last post. With Consort there’s a new desktop environment in preparation and with Mir there’s even a new display server in the making. The later could even be seen as a hostile attempt to sabotage Wayland. More than ever the situation is getting unclear and confusing. Probably a good time to work on the DDD again?

What’s next?

Next I’d like to release a new version of the DesktopDemoDVD.

Qt-based applications #3: Text Editors (2/2)

The last blog entry was about a test of 9 Qt-based text editors (those which I could get to run on Arch Linux). And since the comparison of so many programs and values is not really an easy thing, here’s a second post providing some tables which show the programs sorted not by name but by values.

Overall ranking

Here’s the table with the overall results. The text editors were compared in terms of 1. memory consumption (most important for me and thus weighted *3), 2. disk space used (weighted *2) and 3. size of packages to download:

Rank Text editor Version
01 Minerva GIT20130220
02 CuteNotes 0.9
03 TEA editor 34.0.1
04 Catlooking Writer 1.0
05 JuffEd 0.8.1
06 FocusWriter 1.4.1
07 KoalaWriter 1.0
08 Marave 0.7
09 kWrite 4.10

RAM usage

Here’s the table comparing memory use:

<10 MB 10 – 25 MB 26 – 50 MB > 50 MB
Rank Text editor Version
01 Minerva GIT20130220 4 MB
02 TEA editor 34.0.1 6 MB
03 Cutenotes 0.9 8 MB
03 JuffEd 0.8.1 8 MB
04 Catlooking Writer 1.0 15 MB
05 FocusWriter 1.4.1 26 MB
06 KoalaWriter 1.0 36 MB
07 kWrite 4.10 64 MB
08 Marave 0.7 78 MB

Drive space needed

Here’s the drive space table:

<20 MB 20 – 100 MB 101 – 200 MB > 200 MB
Rank Text editor Version Disk space used
01 Cutenotes 0.9 +1 MB
02 Catlooking Writer 1.0 +2 MB
03 Minerva GIT20130220 +5 MB
04 TEA editor 34.0.1 +6 MB
05 JuffEd 0.8.1 +7 MB
06 FocusWriter 1.4.1 +9 MB
07 Marave 0.7 +154 MB
08 KoalaWriter 1.0 +363 MB
09 kWrite 4.10 +582 MB

Download size

And the download size table:

<1 MB 1 – 10 MB 11 – 50 MB >50 MB
Rank Text editor Version size
01 CuteNotes 0.9 +143 KB
02 Minerva GIT20130220 +319 KB
03 JuffEd 0.8.1 +973 KB
04 Catlooking Writer 1.0 +1.2 MB
04 TEA editor 34.0.1 +1.2 MB
05 FocusWriter 1.4.1 +2,4 MB
06 Marave 0.7 +24 MB
07 KoalaWriter 1.0 +77 MB
08 kWrite 4.10 +126 MB

Conclusion

When it comes to Qt-based text editors, we can see huge differences between them. With Minerva there’s an editor that really deserves the MIN in its name: It does good in all aspects and is the winner in this test. Rank 4 for the Catlooking Writer shows that even those non-distracting writers don’t necessarily have to be extremely resource-hungry. And well, no surprise: kWrite scores the last rank since it depends on the super-heavy kdelibs.

What’s next?

Next I’d like to pick up the DDD again and create a new version. Then I’ll examine the basic GTK+ applications.

This post was written on 02/27 and automatically published. If I didn’t remove that line that means that I still don’t have a working internet connection.

Qt-based applications #3: Text Editors (1/2)

In this post we’ll take a look at some Qt-based text editors. Just like with the file managers I’ll split my post in two parts because there’s quite a number (I found 15!) of such editors out there.

While compiling my list of Qt-based editors, I came across something I hadn’t heard of before. A kind of application which is called non-distracting writer. At first I wasn’t sure whether to include these here, but they don’t fit into the category “Office application” either.
From my point of view they are close enough to text editors to include them here (they are written with the idea that the text is the only thing really important – and that’s pretty much what qualifies them as a text editor, though not a classical one).

The candidates

Here are the text editors that were tested (in alphabetical order):

Not tested

Many of the editors didn’t work right away. I got some of them to work in the end, but these are the ones that wouldn’t work at all and thus were not tested:

If anybody can get one or more of these to work on Arch, please let me know (send me PKGBUILDs?). And also tell me if you think that I forgot anything interesting!

Testing system

For this test I’ve set up the VMs as in my first Qt application test + Virtualbox guest additions this time. Here are the new values:

Arch Linux + Razor-qt (0.5.1)
MemTotal: 4052828 kb
MemFree: 3810544 kb
Buffers: 9972 kb
Cached: 80280 kb
Rootfs: 936560 / 915
RAM used at startup: 242284 / ~237 MB

Catlooking Writer

The Catlooking Writer is a non-distracting writer based on Qt. It’s a full-screen application that’s intended to let you focus on the text only.

Razor-qt with Catlooking Writer

Installation

pacman -U catlooking-git-20130217-1-x86_64.pkg.tar.xz (1222156 Bytes / 1,2 MB)

Statistics

Memory usage after starting up Razor-qt and opening Catlooking Writer via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux Razor-qt+ Catlooking Writer 1.0
MemTotal: 4052828 kb
MemFree: 3795300 kb
Buffers: 9992 kb
Cached: 87616 kb
Rootfs: 938696 / 917M
RAM used at startup: 15244 / ~15 MB
Disk space (less razor system): 2136 / ~2 MB

CuteNotes

CuteNotes is a simple text editor based on Qt.

Razor-qt with CuteNotes

Installation

pacman -U cutenotes-1.0-1-x86_64.pkg.tar.xz (142740 Bytes / 142,7 kB)

Statistics

Memory usage after starting up Razor-qt and opening CuteNotes via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux Razor-qt+ CuteNotes 0.9
MemTotal: 4052828 kb
MemFree: 3802112 kb
Buffers: 9988 kb
Cached: 82472 kb
Rootfs: 937596 / 916M
RAM used at startup: 8432 / ~8 MB
Disk space (less razor system): 1036 / ~1 MB

FocusWriter

FocusWriter is a full-screen, non-disctracting text editor based on Qt. It offers basic support for formats like RTF and ODT, too.

Razor-qt with FocusWriter

Installation

pacman -U focuswriter-1.4.1-1-x86_64.pkg.tar.xz (721800 Bytes / 721,8 kB)
(other packages downloaded as dependencies: 1720320 Bytes / 1,7 MB)

Statistics

Memory usage after starting up Razor-qt and opening FocusWriter via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux Razor-qt+ FocusWriter 1.4.1
MemTotal: 4052828 kb
MemFree: 3784348 kb
Buffers: 10472 kb
Cached: 89492 kb
Rootfs: 946180 / 925M
RAM used at startup: 26196 / ~26 MB
Disk space (less razor system): 9620 / ~9 MB

JuffEd

JuffEd is a tabbed editor with syntax highlighting based on Qt.

Razor-qt with JuffEd

Installation

pacman -s juffed (972800 Bytes / 972,8 kB)

Statistics

Memory usage after starting up Razor-qt and opening JuffEd via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux Razor-qt+ JuffEd 0.8.1
MemTotal: 4052828 kb
MemFree: 3801856 kb
Buffers: 10272 kb
Cached: 88012 kb
Rootfs: 943344 / 922M
RAM used at startup: 8688 / ~8 MB
Disk space (less razor system): 6784 / ~7 MB

KoalaWriter

The KoalaWriter is a non-distracting writer based on Qt. It offers beautiful backgrounds and can even play relaxing music so that you can completely stick to what’s actually important: Your text! It’s a bit heavy-weight, though.

Razor-qt with KoalaWriter

Installation

pacman -koalawriter-1.0-1-x86_64.pkg.tar.xz (16714076 Bytes / 16,7 MB)
(other packages downloaded as dependencies: 60160000 Bytes / 60,2 MB)

Statistics

Memory usage after starting up Razor-qt and opening KoalaWriter via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux Razor-qt+ KoalaWriter 1.0
MemTotal: 4052828 kb
MemFree: 3774164 kb
Buffers: 11544 kb
Cached: 100784 kb
Rootfs: 1308516 / 1.3G
RAM used at startup: 36380 / ~36 MB
Disk space (less razor system): 371956 / ~363 MB

kWrite

kWrite is the default text editor of KDE. It’s quite a bit on the heavy side.

Razor-qt with kWrite

Installation

pacman -S kdebase-kwrite (126095360 Bytes / 126,1 MB)

Statistics

Memory usage after starting up Razor-qt and opening kWrite via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux Razor-qt+ kWrite 4.10
MemTotal: 4052828 kb
MemFree: 3745412 kb
Buffers: 17548 kb
Cached: 108860 kb
Rootfs: 1532732 / 1.5G
RAM used at startup: 65132 / ~64 MB
Disk space (less razor system): 596172 / ~582 MB

Marave

Marave is a non-distracting writer based on Qt. It’s meant to let the user focus on the text rather than the application.

Razor-qt with Marave

Installation

pacman -U marave-0.7-6-any.pkg.tar.xz (1011384 Bytes / 1,0 MB)
(other packages downloaded as dependencies: 23367680 Bytes / 23,4 MB)

Statistics

Memory usage after starting up Razor-qt and opening Marave via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux Razor-qt+ Marave 0.7
MemTotal: 4052828 kb
MemFree: 3730568 kb
Buffers: 11232 kb
Cached: 121844 kb
Rootfs: 1093932 / 1.1G
RAM used at startup: 79976 / ~78 MB
Disk space (less razor system): 157372 / ~154 MB

Minerva

Minerva is a tiny tabbed text editor based on Qt.

Razor-qt with Minerva

Installation

pacman -U minerva-git-20130220-1-x86_64.pkg.tar.xz (319276 Bytes / 319,3 kB)

Statistics

Memory usage after starting up Razor-qt and opening Minerva via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux Razor-qt+ Minerva GIT20130220
MemTotal: 4052828 kb
MemFree: 3806888 kb
Buffers: 9988 kb
Cached: 81580 kb
Rootfs: 942040 / 920M
RAM used at startup: 3656 / ~4 MB
Disk space (less razor system): 5480 / ~5 MB

Tea Editor

The Tea Editor is an advanced editor based on Qt. It offers a lot of features and is still both small in size and frugal in terms of ram usage.

Razor-qt with Tea Editor

Installation

pacman -S tea (1239040 Bytes / 1,2 MB)

Statistics

Memory usage after starting up Razor-qt and opening Tea via the menu (with a second login on tty2) and used disk space after removing pacman cache. Here are the values I got with cat /proc/meminfo and df respectively df -h:

Arch Linux Razor-qt+ Tea editor 34.0.1
MemTotal: 4052828 kb
MemFree: 3804856 kb
Buffers: 10172 kb
Cached: 84644 kb
Rootfs: 942756 / 921M
RAM used at startup: 5688 / ~6 MB
Disk space (less razor system): 6196 / ~6 MB

What’s next?

My next post will provide tables which will make it easier to compare the important values of the programs tested here.

Don’t worry if it takes me a while to publish it – I’m moving houses so time is an even more scarce resource than usually and I might be left without a working internet connection for a while.

Qt-based applications #2: File managers (2/2)

In the last blog entry I tested 8 Qt-based file managers (those which I got to run on Arch Linux). Since that’s quite a bit of stuff, I’d like to present a nice table in this post for easier comparison.

Overall ranking

Here’s the table with the overall results. The file managers were compared in terms of 1. memory consumption (most important for me and thus weighted *3), 2. disk space used (weighted *2) and 3. size of packages to download:

Rank File manager Version
01 Dfilebrowser 1.1
02 ScOpe GIT20130121
03 QtFM 5.1
04 Dino 0.5
05 NewBreeze 1.1.1
06 Andromeda 0.2.1
07 Hamsi Manager 1.1
08 Dolphin 4.9.5

RAM usage

Here’s the table comparing memory use:

<250 MB 251 – 275 MB 276 – 300 MB > 300 MB
Rank File manager Version
01 Dfilebrowser 1.1 230 MB
02 ScOpe GIT20130121 233 MB
03 QtFM 5.1 236 MB
04 Dino 0.5 240 MB
05 NewBreeze 1.1.1 252 MB
06 Andromeda 0.2.1 260 MB
07 Hamsi Manager 1.1 305 MB
08 Dolphin 4.9.5 306 MB

Drive space needed

Here’s the drive space table:

<50 MB 50 – 100 MB 101 – 300 MB > 300 MB
Rank File Manager Version Disk space used
01 Dfilebrowser 1.1 +2 MB
02 Dino 0.5 +3 MB
02 QtFM 5.1 +3 MB
02 ScOpe GIT20130121 +3 MB
03 Andromeda 0.2.1 +64 MB
04 NewBreeze 1.1.1 +74 MB
05 Hamsi Manager 1.1 +295 MB
06 Dolphin 4.9.5 +598 MB

Download size

And the download size table:

<5 MB 6 – 25 MB 26 – 50 MB >50 MB
Rank File Manager Version size
01 Dfilebrowser 1.1 +70 KB
02 QtFM 5.1 +200 KB
03 ScOpe GIT20130121 +243 KB
04 Dino 0.5 +256 KB
05 NewBreeze 1.1.1 +528 KB
06 Andromeda 0.2.1 +13 MB
07 Hamsi Manager 1.1 +51 MB
08 Dolphin 4.9.5 +109 MB

Conclusion

Not too many surprises here. There are some light-weight file managers and a few which offer more features but are also much more heavy weight. Especially in terms of drive space needed and download size the light-weight ones are rather close to each other. Because of that the RAM comparison came out to be identical to the overall rating. Dfilebrowser is the clear winner in our comparison – it scored the first rank in all three categories. ScOpe and QtFM are doing very well, too. Hamsi Manager is a rather ressource heavy file manager and it’s not surprising either that KDE’s Dolphin is the most heavy of the tested applications.

What’s next?

The next entry will take a look at the Qt-based text editors (of which there’s also quite some around).