[openbox] menu format bummy

Marius Nita marius at cs.pdx.edu
Wed Apr 9 13:42:46 EDT 2003

On Wed, Apr 09, 2003 at 02:30:15AM -0500, Ben Jansens wrote:
> On Tue, Apr 08, 2003 at 10:02:42PM -0700, Marius Nita wrote:
> > this is the stuff i was toying with for a general config format. below
> > is the unofficial grammar, and then some examples of what it would
> > look like. 
> Marius, I like this a lot.
> One question: would a and b be presented to openbox identically?
> a) foo.bar.bummy
> b) foo { bar { bummy } }

i wasn't thinking along those lines, but this could certainly be
possible. what i was trying to get across is that the parser would
accept/parse both 'foo.bar "red"' and 'foo { bar "red" }' even though
the first would be accepted as 'id string' and the second would be 'id
block' or something. so the parse tree is different for a) and b), but
since both are accepted just fine, you have a lot of flexibility on
what sort of format you choose for the particular app/module.

> I definately think we should implement this. I'm thinking we need at
> least 3 libraries:
> librender - the low level rendering stuff (Xlib and GL) which the WM uses
>             for window frames
>           - the higher level rendering stuff which tools/apps/WM can use
> libcwmcc  - routines for getting/setting icccm and netwm
>             properties/information. similar to the libwnck? that is part of
> 			the gnome project

this rules

> libsomethin - contain this parsing stuff for both the WM to use for the rc3,
>               librender to use for themes, and tools could use for their own
> 			  configs
> 			- other stuff that can be used by the WM, librender, and or
> 			  tools

libcl or libobcl or libgcl or something (gcl == generic config language)

> libotk - i'm not sure about this one, but it could be built using the
>          high level interface in librender and libcwmcc. some of the things
> 		 that could go in here could also be placed into the other libs
> 		 instead

ah, good ol' otk :) personally, i'm leaning toward the maximum
possible amount of simplicity, at least for our initial release
plans. if we write otk, it should probably offer only one type of
widget with limited capabilities (nest other widgets, have a texture)
and which can handle high level events, like click, double click, etc.
tools can gain netwm and config parsing power by linking to other
libs. we'll talk about this again once the other libs stabilize their


More information about the openbox mailing list