Moving to metacity. Metacity makes both screens have the same number
of workspaces. Personally, I think this makes sense, but maybe Havoc
has different ideas ...

I wouldn't even call this major, but... that's me. It's probably not
just metacity, of course- gnome-settings-daemon would have to be
changed as well, I believe.

If you want X workspaces on screen 0, and Y workspaces on screen 1,
then one could always set MAX(X,Y) spaces and ignore the extra ones...

The workspace names perhaps have more reason to change per-screen.

I asked how this should work earlier - there's a bug with some
discussion, I believe it works as Mark told me it did with dtwm... 

Havoc: I doubt I told you it works with dtwm 'cause I've very, very
barely used dtwm, never mind in a multihead setup (I've never actually
seen GNOME running with a multihead setup :-) ...

*** Bug 91980 has been marked as a duplicate of this bug. ***

As requested by Havoc, here is how dtwm handles workspaces on
multihead support:

- dtwm keep a separate list of workspaces for which screen it manages
on the
  display.
  This means :
  - one can was an arbitrary number of workspaces on each each screen.
  - each workspace is unique, this means that there is no relation 
    between workspaces on different screens.

Here is a little background on how people often use multihead setups
instead
of xinerama.

Multihead setups are often used by :
- CAD engineers : they have one or two screens with hardware
acceleration 
  to render there designs (e.g. 32 bits stereo mode or hardware opengl 
  acceleration) and one or more "normal" screens (8-24 bits without
  acceleration) to display the "toolbox", terminals and productivity
apps.
  
- TelCo & co: they use one screen to monitor the system (e.g. graphic
map 
  of the system) and the other screens for the options (e.g. a set of
  dialog boxes).
  
- Stock traders : they usually use 3 screens, 2 to monitor the trands
  (e.g. realtime graph) and one to place orders and communications.
  

So in this context it makes sense to have completely unrelated
workspaces
on each screen.

(if you want more example let me know)

  HTH,
      Erwann

I've just committed a big patch to make metacity work 
more or less like dtwm. Probably still has some issues.

Still need to add separate gconf prefs for the number of spaces 
and appropriately track those, I think from a user standpoint 
they'll have a pager per-screen, so this pref should be per-screen
as well.

Good stuff Havoc.

Erwann: you were talking about checking this out ?

Batch change. Sorry for the spam.

*** Bug 302846 has been marked as a duplicate of this bug. ***

Remove old target milestones on old bugs; sorry for the spam.

*** Bug 108681 has been marked as a duplicate of this bug. ***

*** Bug 448537 has been marked as a duplicate of this bug. ***

(In reply to comment #13)
> *** Bug 448537 has been marked as a duplicate of this bug. ***
> 

Please, could you consider raising the level of Priority / Severity ?

Kind regards
Manfred

--

Please cf. http://bugzilla.gnome.org/show_bug.cgi?id=349559#c12 :

   " ... clasified as "minor " (!?!) ... "

   " ... where you defenitely _cannot_ work with "one big screen". "

   " Is this, because the internal structures of metacity do not cleanly reflect
multiple screens? "
   " Or what else blocks clear separation? "

   " For some clients, this is a knock-out reason against Gnome rightaway. "

Manfrid: I suspect your issue is not the same as this bug (in particular workspaces are separate per screen already); my comments are in bug 349559, let's follow up there first.

As determined in the other report, Manfred was indeed talking about this bug.

Elijah,

after a short look into the Gnome / Metacity sources, unfortunately it really seems necessary to re-view the structures ...

Even the configuration structure itself reflects the shortcoming:

num_workspaces is a One-and-Only parameter right below /apps/metacity/general -
with no dependency upon any gnome construct reflecting the X11 "Screen" construct at all.

In my case, 
               # gconftool-2       -R   /apps/metacity/general
reveals
                   ...
                   num_workspaces = 30
                   ...

In order to change it, I can only command e.g.
    gconftool-2 --type=int --set /apps/metacity/general/num_workspaces 32

Correspondingly, the same unawareness applies to 

                /apps/metacity/workspace_names/

holding the One-and-Only list of the configured names.

So, naturally, this can work in Xinerama cases,
but never in MultiHead configurations.

Looking forward to hearing from you!
Manfred


Postscriptum:

  Priority / Severity:   still  "minor"  ?

  Gnome Version:         2.18.1
  Gnome target:          ???

Sorry: I forgot to mention:

- I downloaded and looked at version 2.19.21.
- 2.18.1 was in the 7.04 Ubuntu release with which I tested the Matrox DualHead -
- c.f. http://bugzilla.gnome.org/show_bug.cgi?id=349559#c16 ff.

Elijah, 
the following findings do indicate that screen handling in fact _is_ already reflected in 2.19.21:

screen.h:
struct _MetaScreen { ... Screen *xscreen; ... }            <<< o.k.


core.c:
int meta_core_get_num_workspaces (Screen  *xscreen) { ... }    <<< o.k.

screen.c:
static void set_workspace_names    (MetaScreen *screen);        <<< o.k.


O.K. so far - but:


screen.c:
void meta_screen_update_workspace_names (MetaScreen *screen) <<< o.k.
{
... 
 while (i < n_names)
    {
     ...
      meta_prefs_change_workspace_name (i, names[i]);         <<< missing
     ...
    }
...
}

The reason:
  gnome preference handling does not contain any screen dependencies at all!

prefs.c:
int meta_prefs_get_num_workspaces (void)                      <<< missing
void meta_prefs_set_num_workspaces (int n_workspaces)         <<< missing
void meta_prefs_change_workspace_name (int i, const char *name) <<< missing


So, somehow Vincent _was_ right in estimating the bug might be "only" a config handling problem (http://bugzilla.gnome.org/show_bug.cgi?id=349559#c14)!

Looking forward to hearing from you.
Kind regards
Manfred

Hi, Vincent,

I tried to quickly get an impression what would be involved to correct the situation.

Does the following approximately picture it correctly?

------- snip ---------

gconftool-2: 
is not involved - it operates on key/value-bindings in an abstract way.

metacity.schemas:
does not seem to be involved; reason: handling is per-screen.

workspace.c:
window.c:
They seem to reflect the screen dependency already; right?


To me, it seems that the main changes have to be applied quite localized into 
prefs.c:
========

#define MAX_REASONABLE_WORKSPACES 36
#define MAX_REASONABLE_SCREENS     4      # <<< two graphic adapter cards 
                                          # <<< with two heads each;
                                          # <<<        e.g.: 2 x PCI-X-16

#define KEY_NUM_SCREENS            "/apps/metacity/general/num_screens"
#define KEY_SCREEN1_NUM_WORKSPACES "/apps/metacity/general/screen1/num_workspaces"
...
#define KEY_SCREEN1_WORKSPACE_NAME_PREFIX "/apps/metacity/screen1/workspace_names/name_"
...

static int num_screens = 1;
static int num_workspaces[MAX_REASONABLE_SCREENS] = {4, 0, 0, 0, };
static char *workspace_names[MAX_REASONABLE_WORKSPACES] = { NULL, };

static gboolean update_num_workspaces[MAX_REASONABLE_SCREENS]  (int         value);

static gboolean update_workspace_name[MAX_REASONABLE_SCREENS]  (const char  *name, const char  *value);

static char* gconf_key_for_workspace_name[MAX_REASONABLE_SCREENS] (int i);

void meta_prefs_init (void) {...}  :
needs LOOP over num_screens;

static void change_notify (...) {...} :
needs to become dependent upon the screen id;
this has to be reflected where the event is initiated.

Accordingly enhancements have to be applied to :

    update_num_workspaces :
    queue_changed (META_PREF_NUM_WORKSPACES)
    int meta_prefs_get_num_workspaces (void)
    int meta_prefs_set_num_workspaces (void)
    static void init_workspace_names (void) {...}
    const char* meta_prefs_get_workspace_name (int i){...}
    void meta_prefs_change_workspace_name (...) {...}
    static char* gconf_key_for_workspace_name (int i){...}
    static gboolean update_workspace_name (...) {...}
    const char* meta_preference_to_string (MetaPreference pref) {...}

I suppose, these can stay unaltered, because handling is per-screen :

    static MetaKeyPref screen_bindings[] = {...}
    static MetaKeyPref window_bindings[] = {...}
    static MetaSimpleKeyMapping screen_string_bindings[] = {...}

(In reply to comment #20)
> Hi, Vincent,

SORRY: I meant:

Hi, Elijah,

I think it would be important to continue honoring the current gconf keys to mean the fallback default setting for all screens. 

That is, don't start ignoring general/num_workspaces and only look at general/screenN/num_workspaces ; instead, read general/num_workspaces and then screenN/num_workspaces, and if any screenN are unset, use the existing gconf key for the default.

This effectively means that people can ignore the new per-screen complexity if they want to, and their current settings won't be lost, and the current control panel will still work (at least until people manually put in an override).

Re: some of the details

1) I don't think num_screens should have anything to do with gconf. The way metacity works is that it manages all screens on the display that are not already managed by another WM. If you were going to make this configurable, you would have to have a list of screens to manage. But I think we've had maybe one or two requests to make it configurable in 5 years and "start another WM first" is an adequate workaround, so I would say it is thoroughly not worthwhile. (There is another - likely closed - bug if this is something people want to discuss/reopen, I don't mean to derail this bug, please discuss it on its own bug.)

2) you will need .schemas changes to document the new keys, and in particular that they override the global (all screens) prefs.

(In reply to comment #22)
> ... fallback 

Great!

> ... and then screenN/num_workspaces ...

Did I understand you right that you propose to newly intorduce these "screenN/" dictionaries into the (default) config tree? 

> ... (at least until people manually put in an override).

Super.

> 1) ... metacity ... manages all screens on the display that are not
> already managed by another WM. If you were going to make this configurable, 

Sorry, Havoc, I'm not a gnome/metacity dev. at all; 
could you please be so kind as to point me to how this "make ... configurable" is evtl. related to my post above?

Kind regards
Manfred

> Did I understand you right that you propose to newly intorduce :
> these "screenN/"
> dictionaries into the (default) config tree? 

I would make screenN unset by default (just set the fallbacks).

> could you please be so kind as to point me to how this "make ... configurable"
> is evtl. related to my post above?

I thought some of your example code implied a gconf setting for number of screens. If you weren't saying that, then disregard.

I guess I should not have called it

    #define MAX_REASONABLE_SCREENS     4

but perhaps

    #define MAX_REASONABLE_XSCREENS    4
or
    #define MAX_REASONABLE_DISPLAYS    4

would have been better? Perhaps this is the cause of mis-understanding?

But I'm not really sure I grasped the gnome terminology correctly yet:

  - xscreen
    - display
      - screen     <-- workspace-switcher
        - windows

- A display is a keyboard and mouse, plus one or more monitors.

- Each monitor is generally a screen, also called a root window. So a display has one or more screens. (Xinerama lets you merge multiple monitors into one screen, but ignore that here.)

- each screen has workspaces, which are possibly-intersecting sets of windows

- each screen has windows, which are on workspaces

(In reply to comment #26)

Thank you very much!

> - A display is a keyboard and mouse, plus one or more monitors.
    X:  "ServerLayout"

> - Each monitor is generally a screen, also called a root window.
    X:  "Screen"

> - each screen has workspaces, which are possibly-intersecting sets of windows
    The allocated screen areas of the workspaces are disjunct, right?

> - each screen has windows, which are on workspaces

I guess, the panels are windows on workspaces which always stay on the edge of the root window,
whereas the workspace switcher switches between the "central/major big working area workspaces" containing its respective particular application windows?
 
Is it possible to attach one instance of a workspace identically to more than one screen? Esp. e.g. a panel?
Or is coincidence of panel elements docked to panels achieved by the docking mechanism?

This could possibly relate to my observations in 
http://bugzilla.gnome.org/show_bug.cgi?id=349559#c18 .

But that surely should be a different separate bug than this one?

bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years.

If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/

Thank you for reporting this issue and we are sorry it could not be fixed.