On Wed, 2009-08-12 at 00:16 +0200, Mads Villadsen wrote:
> On Tue, 2009-08-11 at 20:31 +0000, Colin Walters wrote:
> > On Tue, Aug 11, 2009 at 8:22 PM, Mads Villadsen<m...@krakoa.dk> wrote:
> > > Attached is a small patch that uses libwnck to make sure the workspace
> > > layout
> >
> > I'm not too familiar with the concept of workspace layout, so I'll let
> > someone else respond to that. But:
>
> Just to clarify what I am hoping to achieve: When adding workspaces in
> gnome-shell the number of rows in the workspace list grows to accomodate
> the new workspaces. However when using <Ctrl><Alt>-arrowkeys to change
> workspace the layout is always in one single row.
>
> So I wanted to make sure changes made in the gnome-shell workspace view
> got reflected in the internal workspace switcher as well.
>
> > > is synced with the window manager.
> >
> > We *are* the window manager. Using libwnck inside the mutter process
> > is not a good idea, we end up talking to ourselves over the X server.
>
> I hadn't thought about it that way - but you are of course right.
>
> > > Any hints on how to make it cleaner will be greatly appreciated.
> >
> > You should call directly into MetaDisplay, MetaScreen functions to
> > accomplish what you want.
>
> However as far as I can tell there isn't really a way to set the layout
> from either MetaDisplay or MetaScreen - and it even appears to be by
> design.
The API exported by Mutter is not a fixed quantity - very frequently we
are doing things that never made sense in the original Metacity code so
we have to extend the API to do that.
In this case a simple API might be:
void meta_screen_override_workspace_layout (MetaScreen *screen,
int rows_of_workspaces,
int
columns_of_workspaces,
MetaScreenCorner starting_corner,
gboolean
vertical_workspaces);
There wouldn't be any we of "unoverriding" - once you overrode the layout
it would stay overridden. Should be trivial to implement with a 1-bit flag
in the MetaScreen structure.
> I don't think there is any inherent problem in having the pager be an
> in-process part of the window manager, but I think it makes sense to
> reuse libwnck as it probably handles a lot of corner cases.
>
> Another option would of course be to somehow catch an event caused by
> pressing <Ctrl><Alt>-arrowkeys, and then do all the drawing with clutter
> - it would have the added advantage of looking nicer.
We likely will eventually want to replace the workspace switch popup
just as we replaced the Alt-Tab popup. But it's probably still useful
for the core to understand the layout. To know what happens when the
user hits <Control><Alt>-Right for example.
Hmm, the other issue here is the funky layout we use - when we have more
than four workspaces, we don't actually number them in any intuitive
fashion, but, for example:
1 2 5
3 4 6
7 8 9
(This is to avoid having to move existing workspaces around.) Options
for this:
- We could drop the funky ordering and just move stuff around.
- We could renumber workspaces behind the scene as things are added
- We could make the API something different
struct _MetaWorkspacePosition {
int row;
int column;
};
void meta_screen_override_workspace_layout (MetaScreen *screen,
int n_workspaces,
MetaWorkspacePosition
*workspace_positions);
I think this is probably the best way to go, though it's going to require some
more rewriting within Mutter. (It's OK to use O(n_workspaces) algorithms to do
things
like "find the workspace to the right of the current workspace")
Unfortunately, neither gobject-introspection or gjs (for separate reasons)
can handle the above prototype. The easiest thing to do is just to add:
void shell_global_set_workspace_layout (ShellGlobal *global,
GSList *workspace_positions);
and convert GSList to an array and call the new Mutter function from there.
(I don't want to do distort the Mutter API for temporarily limitations of gjs)
- Owen
_______________________________________________
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list
