Re: extending metacity

On Thu, 2008-09-04 at 18:57 -0400, Thomas Thurman wrote:
> libmetacity-private is, well, private: it's there because the theme 
> viewer links to it so the code isn't in there twice. 

No problem, I just wanted to check. The .deb doesn't mention it is

>   1) You need a way to identify windows of the same type.  This is 
> actually quite a tricky thing to do; there is a standard way to signal 
> that your windows are all the same kind, but not all apps obey it-- even 
> the ones you might expect to.  We do do this already, though, so you can 
> piggyback off that.

Yeah, I thought that might be the case. All apps I'd really care about
are Free, so I could at least submit patches if they don't support it.

>   2) You need to modify the frame code so that it includes a tabbed 
> notebook, and then to map and unmap the windows as appropriate when the 
> user chooses a window.  This bit will be new.

Right, right. So Metacity has this MetaFrame GObject that seems to be
responsible for painting the frames. Because Metacity supports themes,
this doesn't really use any actual GTK+ controls, right? But because
MetaFrame inherits from GtkWindow I could in theory add a GtkNotebook to
that and maybe use the theme to paint the tabs or just ignore the theme
titlebar for any tabbed windows.

(Sorry for the newbie questions, I'm familiar with pygtk but not GTK+ in

> If you work on this and get something working, though, I encourage you 
> to discuss whether your changes should form a separate WM or be merged 
> back into Metacity and have an on/off switch in GConf.

Okay cool. I'll hack on it on a private branch or something as I have
the time.


⎊ Michael Gratton. "Mea navis aëricumbens anguillis abundat."
⎈ <>

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]