Ninja Foo & Spaghetti Sauce

[Marius Nita]

So regarding Openbox 2. Woodblock and I talked about further development a
little bit this morning, and I want to outline some thoughts/ideas that would
be good[tm] but which may also seem far fetched and weird, bummy-like. Anyway.

Otk
----

We need a toolkit. Xor and I talked about this long long ago before openbox
existed; we need a non-sucky way to build visual WM elements. Current ob/bb
sucks hard at this, as many items are drawn "in place"--instead of saying "hey,
nice class that i wrote, pls give me this kind of visual element" it says "oh
i need to draw xyz. let's use the X primitives right here in the middle of
this 1200 line function to draw it." That's bad, weird, and weird. Fast, you
say? PFFT!

We need high level classes like the following:

	OtkLabel
	OtkButton
	OtkTitle
	OtkMenu
	...

which rely on low level classes like the following:

	OtkTexture
	OtkFont
	OtkTextContainer
	OtkImageContainer
	OtkImage
	...

Some would probably be abstract, and there would be an inheritance hierarchy
with OtkObject at the top, probably. This hierarchy will not be huge, and the
classes will stay small.

Then, putting a toolbar on the screen, would be something like (inside the
Toolbar class):

  OtkTitle *title = new OtkTitle(x, y, width, height);
  OtkLabel *wksp = new OtkLabel(small_lbl_width, lbl_height);
  OtkLabel *win_name = new OtkLabel(lbl_width, lbl_height);
  OtkLabel *clock = new OtkLabel(small_lbl_width, lbl_height);
  OtkButton *leftwksp = new OtkButton(btn_width, lbl_height,
                                      foo->getPixmap(OtkButton::LeftArrow));
  OtkButton *rightwksp = new OtkButton(btn_width, lbl_height,
                                       foo->getPixmap(OtkButton::RightArrow));
  // same for next_win, prev_win

  title->setJustify(Otk::JustifyLeft);
  title->addItem(wksp);
  title->addItem(leftwksp);
  title->addItem(rightwksp);
  title->addItem(win_name);
  title->addItem(prev_win);
  title->addItem(next_win);
  title->addItem(clock);

  wksp->setText(current_workspace_name);
  clock->setText(clock_string);
  win_name->setText(getCurrentWindow()->getLabel()->getText());

  title->map();

  // or something like that.

Far fetched? Probably. Cool? Damn right. You can now imagine how the rest of
openbox' visual presence gets put together. Now, the toolkit would be
incorporated into libob. The obtools can then take full advantage of the
drawing niceties that openbox takes advantage of. They'd be using exactly the
same code. Menus are themselves composed of Otk elements, and are offered as
high level elements themselves. You can instantiate menus, add items to them,
even nest them in other structures. You can nest a menu into the toolbar, or a
toolbar like element.

The toolkit collaborates with the style engine under the hood. To keep
backward compatibility with blackbox styles, we'd need our Toolbar to access
the style engine, since it's a style element. However, a consistent style
would specify style elements for the titles, labels, buttons, frame, and the
other ob specific elements: grip, etc. The toolbar and window styles would be
deduced from these lower level specifications. even currently, the
overwhelming majority of styles dupe large amounts of style data so they
achieve consistency... However, i can understand the need for fine touches and
the various elements of the WM, and this should be able to be accomplished.
Even then, you would specify the primitive info, and if you say, want to add a
text shadow to the toolbar only, then that's the only additional element you
need to specify. Basically, this would eliminate redundancy from styles.

Now, since this toolkit is so versatile, the toolbar can easily be removed
from the window manager, and written in a couple of hundred of lines of code,
using libob and libob's netwm and Otk capabilities. Same goes for any obtool.
Obtools will write the code that composes their look from these toolkit
primitives, and the look will be enforced by libob. They won't be able to
change say, the gradient type/color of OtkLabel, but they will be able to
customize things where we find suitable to allow them.

Removing the drawing nastiness from the WM core will simplify things GREATLY,
making ob2 more fun to hack on in the future, and extremely versatile and easy
to modify and improve.

This is sort of like the engine concept in ob3, but not quite. There will be a
"main engine" and that is openbox itself. Openbox uses the toolkit to
construct its visual elements. So the separation between decoration and
Openbox is not as concrete as in ob3. We could separate the decoration code
from the WM code, as in different dirs, but the decoration code wouldn't be in
an .so or anything...

A better class hierarchy in the WM
----------------------------------

The current arrangement of classes in ob2 sucks. We all know this, we complain
about it all the time. It's part of what has driven us to start ob3. To
immediately improve ob2, we need 2 things:

	BaseWindow
	XEventHandler

Now these are affected by the toolkit above to a certain extent, but the
problems we need to address are:

	- We need to be able to treat most of the screen elements as Windows,
	  such as the slit, and that little annoying thing that displays the
	  coordinates. The current way of handling stacking is a nightmare.
	  The slit, toolbar, menu, little annoying coordinate thing, all need
	  a concrete place in the Z-stack so they need to be manipulated
	  similarly. Right now, it's a nasty combination of XLower* XRaise*
	  and throwing the ob-specific windows on top of the other windows
	  when the screen stacks things up.

	- We need event dispatch to not suck. searching through all sorts of
	  lists to find the window you need is bull. The dispatcher need not
	  know which windows handle which events. You get the event, you
	  get the element, you call handleEvent() on it. Done.

Other stuff
-----------

blackbox.cc and its relationship to BaseDisplay is a mess. We need to separate
these things, and probably move event dispatch into BaseDisplay.

And um, more later, as I think about it.

marius