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.