Saturday, March 22, 2008

A Generic HTML Applet

Life has decided to sneak up and pound me over the head with a large, heavy object recently... consequently I haven't gotten a lot done in awn land. And don't necessarily expect to accomplish much in the the next couple weeks.

That being said I have started some work on a generic HTML applet. In a fit of originality I have called it webapplet. It is in awn-extras but it will not build unless you use the --with-webkit configuration option. You will need to have webkitgtk installed as it is a webkit only beast at the moment. I also don't believe the configure script is checking for webkitgtk at the moment... I'll need to nicely ask malept to look into that for me.

Anyway, it's not doing a lot at the moment but it does have some ambitions:
  • Try to stem the proliferation of hundreds and thousands of individualized web applets :-)
  • Option of webkitgtk and/or gtkmozembed renderer. I will not add the gtkmozembed until after I am happy with the webkitgtk implementation.
  • Support for as many of the web widget formats as possible. And yes there is an intent to support Apple Dashboard widgets if possible.
  • Ability to easily configure it for new pages/widgets.
  • A collection pre-configured pages/widgets. I'm thinking stored in a keyfile backend. The goal is for the user to start up the configuration and be able to either choose from a selection of pre-configured options or add their easily own.
Anyway, just something I've been working on a bit when I've been in a coding mood. I'll post more as it progresses.

PS njpatel has been making a few interesting commits this weekend.

Sunday, March 9, 2008

Why things are the way they are...

A rather constant theme recurs in many blog posts and forum threads. Often the statements in question are factually correct but, I think, miss the nuances of the cost involved with each choice. These themes are often framed along the lines of:
  • AWN is more stable than xyz.
  • Why doesn't awn have shiny feature like the parabolic zoom in abc?

Some might disagree with me but I actually think these two statements are two sides of the same coin. And it all comes down to how applets are handled in AWN versus some other docks.

There are fundamentally two approaches that can be take to applets.
  1. Everything, including the dock and all the applets, run in the same process space.
  2. Every applet runs in a separate process space and the dock itself runs in a process space of its own.

Now in reality it is possible to mix these two approaches. And at the moment AWN does just that; the core taskmanager/launcher applet and the separator applet are not really applets, instead when they are in the applet lists it activates code running in AWN core. This will be changing with the 0.6 release of awn when the launcher/taskmanager code will be officially moved out of AWN core into applets. (Yes I have been working on an experimental implementation of this already... but it is experimental). Obviously, some of the other docks choose a different path.


What are the tradeoffs:
  • If everything is running in the same process space it's much easier to do bling. It's possible to easily and efficiently toss cairo surfaces (for example) around in a nice and shiny manner:-) In AWN's situation each applet(process) has it's very own window which makes it far more difficult to perform certain types of magic (yes we know many of you want a parabolic zoom... but it's hard, though maybe not impossible, to do with this architecture). Basically, unless we implement some compiz style window based effect engine it is necessary for each applet to handle its own effects though coordination is possible through IPC (d-bus for example), and this is what we are doing. (yes there are plans to improve this.. we have not reached the limits of bling possible)
  • Separate processes mean more stability. If programmers were perfect this wouldn't be true. But programmers are not perfect. By separating each applet into it's own process space it makes it very unlikely that an error in one applet will bring down the whole house of cards. A shared process space situation tends to be a lot more dodgy. On the same note it makes it easier for applet devs to contribute. It's all about a low barrier of entry and there is a fairly low barrier for AWN applet developers... you don't need an indepth understanding of the internals of AWN to write an applet for it.
  • A single process uses less resources. Even though the additional resource usage of multiple processes might not be as great as one would think, it can still be a significant cost. In the case of AWN I would have to say you pay a cost of a bit over 1 megabyte for each C applet versus a situation where everything ran in the same process. And that is a best case number.
  • One process per applet lends itself to allowing a diverse environment for developing applets. Currently AWN supports C, Vala and Python applets and it lends itself well to the addition of others. This attracts applet devs. The more applet devs the more applets you get. And applets are good.
So, it really is a case of tradeoffs. I won't say with certainty which ones is the best choice... it ultimately depends on the user in question.