Incorrect screen positioning when using multiple displays (TwinView)

If the screenshot is confusing, I apologize. The top part is my external monitor (which has a lower resolution than my laptop, and thus the gap on the right) and the bottom part is my laptop screen. This is a single screenshot of my TwinView setup. Both windows (top and bottom) are maximized and display the reserved space for the AWN bar on the incorrect display.

Note: I'm having this issue only with my second display in 8.10 (beta - completely up to date) Using builtin Nvidia drivers.

Avant Window Navigator 0.3.1 running on Ubuntu 8.04 also has this problem.

If it used to work for you in this exact setup, then you were experiencing broken behavior. What you are trying to do is put a 'strut', a window docked on a monitor edge that takes space away from maximized windows, and place it on an 'internal edge', an edge shared by two monitors--in this case, the edge in common between your external monitor and your laptop's screen.

5 years ago when the specification for supporting such struts on multiple monitors was designed, it was unfortunately decided to limit struts to be defined only on the overall virtual screen's dimensions, not relative to any specific monitors in order to keep things a little more backwards compatible. (http://markmail.org/message/ojtfzu6ce5fhr3mp#query:_net_wm_strut_partial%20internal%20edge+page:1+mid:ojtfzu6ce5fhr3mp+state:results)

The last attempt to fix this was in 2004, but died off from lack of interest (http://markmail.org/message/igxshkvtoiftxxaz#query:_net_wm_strut_partial%20internal%20edge+page:1+mid:svlu42opykargpej+state:results).

With the advent of LCD displays with resolutions of 2560x1600, there is a much more significant need for supporting docks on internal edges. With a mjaor distribution like Ubuntu pressing, maybe the specs will be updated to support such a feature.

That said, if the functionality you desire worked before, either you were placing AWN on your bottom monitor or it was a bug with your window manager (Metacity, judging from the screenshots)

The attached bzr bundle/patch is against trunk and fixes the following:
* Building against GTK with GTK_DISABLE_DEPRECATED defined
* GObject-ify AwnSettings so that AwnMonitor functionality can be merged in
* Merge AwnMonitor and duplicated AwnSettings entries so monitor geometry is only stored in 1 place instead of 3.
* Don't assume the top-left corner of the desired monitor is (0,0) when placing windows
* Set strut values that actually conform to spec (relative to overall screen edge, not monitor edge)
* Remove all force_* settings in favor of one monitor_num setting
* Add a 'monitor number' spinbox to the Bar Appearance tab of awn-manager to update the monitor_num setting
* Automatically update if GTK receives a "monitors-changed" due to screen hotplugging

With these changes, no more algebra is required to calculate unrealistic values for force_width and force_height to get the bar to appear on a second monitor. Nor does it require manual changes if your a laptop user and only occasionally have a external monitor attached.

It does fix setting the the struts for users with multiple monitors of multiple resolutions in a horizontal configuration.

It may or may not fix setting struts for internal edges in metacity or other WMs... but if it does, it's non-standard behavior in the WM and shouldn't be relied upon.

Thanks for the patch :)

After some testing (I have 2 monitors 1280x1024, Twinview and awn set up in the middle of the left screen, using compiz) :
* You need to add to awnDefine.py.in : MONITOR_NUM = "monitor_num"
* When you set 2 to monitor_num, awn is set up on the right, in the middle, and maximized windows on the left cover the all screen. So it's the expect behavior.
* When I set 1 or 0 to monitor_num, it's the same behavior than before : awn in the middle of the left screen, but maximized windows are not fullscreen.

I needed to do some trick sometimes ago on my xorg.conf to have awn in the middle of left screen, so it's maybe now a problem.

And metacity seems to not have this problem (maximezed windows cover properly the second screen) with current awn trunk.

I let moonbeam or malept comment the whole patch :)

As Julien said, thanks for the patch. My opinion is that it is way too invasive as it currently stands to be committed to trunk. However, I would like Neil to look over how the monitor code has been changed, and incorporate it into the rewrite (when he has some time, of course).

When I have some more time, I'll go over some of the smaller things that the patch covers, such as build system fixes and deprecated API.

The bundle contains a series of commits that more or less can be applied individually. The later three directly deal with positioning and don't depend too much on the prior commits.

The changes sorted by my opinion of 'invasiveness', from most to least:
1. Updated docs files: Some types might have been purposely excluded in the past because they were considered 'internal'-only, despite being exposed from the library.

2. GObject-ify AwnSettings: It needs to be done at some point.
    * Having a nice singleton to maintain settings in a central location is a nice convenience. Having to break ABI for each setting you change or remove is not.
    * GTK+ has hit this same issue, which has prevented them from adding some features because it changes struts defined in public headers.
   * Accessor functions or GObject properties don't have this limitation.
   * A central settings manager that refreshes external updates is no good if its clients have to poll it for changes. GObject's "notify" signal is a trivially implemented solution that fits in with the rest of the GOBject-based codebase
  * ABI for the AwnSettings struct has already been broken twice in the past 4 months
  * Theoretically, since a maximum of one instance of AwnSettings will exist, there is no harm to not pairing g_object_unref calls with awn_settings_new calls; it's just a convenience for memleak debugging with Valgrind.
  * The next step would be to create accessors or properties for all the fields in AwnWidget and seal the members of the struct with GSEAL a'la GTK. Then after a major release with GSEAL enabled to give external applets time to do things right, move all the settings fields in the struct to a private struct instead of exposing it to the world.

3: Showing panel later after position is set:
   * Don't show the window before setting the position ourselves
   * Otherwise WM position AWN in some random place (possibly depending on mouse position) before we immediately move it to another location.
   * GTK was just going to put the window on the default screen anyway, so get the default screen without requiring the window to be realized first.

4. Use monitor.x and monitor.y when positioning windows
   * The change is simple: add monitor.x to the x value, and similar for y.
   * It's only so invasive because there's so much duplicated code in static functions in each of the .c files for the various windows.

5: Removal of AwnMonitor: It's not in libawn, but only in the source tree for one window that wasn't actually even using it.

6: Remove deprecated functions: the alternatives are functional equivalents and have been around since Gtk 2.0

7. Awn Applet dialog placement: use the monitor bounding box rather than 0..screenWidth

8. Deprecate awn_get_settings or not. Having two functions that do the exact same thing is pointless. Deprecate it like GTK+ does and leave it in, but conditionally compiled. This way you don't break ABI, but people know better than to use it and have a better chance of their code working as-is in the future.

9. autogen.sh changes: harmless unless you expect autogen.sh --prefix /usr to put files in /usr/local

All in all, the only API and AB...

I appreciate the breakdown of the changes made. The important thing to note is that the API of trunk and the next major version of Awn is significantly different, mostly due to the rewrite that Neil is currently making in a separate branch. Among the changes is the removal of AwnSettings. This is pretty much the reason why I made the statements in my previous comment.

Ah, good to hear. I didn't know about a rewrite, and normally one expects to find the latest bleeding edge code in trunk. I haven't been following or using AWN until just recently when I got Openbox to work properly with shaped windows like AWN uses.

I just took a look at the 'trunk-rewrite-and-random-breakage', and it looks like the positioning fixes would be relatively straightforward and much cleaner.

Basically, all Neil would have to do is add 'x' and 'y' properties to the AwnMonitor, move all the monitor-related stuff from AwmSettings to AwmMonitor, use x,y in awn-window:position_window.

The strut related code looks like practically a drop-in replacement, although it'd need generalized for all four edges.

Everything else is probably irrelevant to the new branch; if I had known, I would have based my patch against it.

Thanks dynamotwain,

I'm now running a twinview setup on my work laptop. So I'll definitely be giving this a test.

Since the code is available I think some consideration should be given to applying this to the current trunk (especially if we end up doing a 0.3.2 release) assuming testing doesn't show any major issues. My view being that once this shows up on a blog or forum posts somewhere people are going to start (trying) patch/build with this and the extra support that will cause probably outweighs what would happen if we applied this to trunk and had it filter into the various packages.

Regarding it not being present in trunk we tend to prefer to do the bleeding edge stuff that actually breaks a _lot_ of things in a separate branch. Admittedly this can cause some issues but it does work relatively well. If you ever want to check what/where current work is happening I'd suggest dropping by #awn on freenode.

I've done a build with the patch and I'm noticing that customize effects options in the general tab of awn-manager has the text running together. I'm not sure if this is caused by the changes to awn-manager but this is the first I've noticed this so I suspect it is (I will revert back and test once I get a chance).

I

After a re-config of my xorg, some more testing :
- when you change the setting on monitor in gconf, the bar is not updated. If list of windows change, the icons move slowly without the bar.
- when I set it to 0, the bar is on the middle of the left screen, but maximised windows on the right don't cover all the screen.
- when I set it to 1, the bar is on the middle of the right screen, and maximised windows cover all the left screen.

System : Ubuntu 8.10, nvidia 177 drivers, compiz.

You have to close and restart AWN after changing the monitor. These are things AWN had wrong before because AWN currently stores all of its settings in a AwnSettings class (which gets updated when the GConf values change) but it doesn't propagate those changes to the rest of AWN. AwnPanel, AwnHotspon, AwnBar, etc would all need to be notified of configuration changes (they currently aren't) and then deal with them correctly. You would have the same problems if you toggled the force_monitorm, monitor_width, or panel_mode settings before my patch.

In Neil's trunk rewrite, AwnSettings goes away and everything that actually cares about the settings has its own notify function such that the correct behavior you and I both desire can be obtained... but with the infrastructure currently in trunk, it's just not feasible without a huge amount of effort that ultimately boils down to one of the changes in the trunk rewrite: properly responding to configuration changes.

I have the same issue, but just with one monitor.

I have the bar in auto-hide, but it doesnt really matter, because when you maximize any windows its like the bar is still there

Some issue here as pointed by dynamotwain
The panel of the dock does not get relocated after I add a new monitor (with a bigger resolution.)
This does not happen to the icons that instead are relocated correctly.

Should we use the development branch instead of the stable where, If I understood correctly, the bug is closed due to the complete rewrite of the settings control?
Is it a good idea?

Is this still being looked at, or have these changes been added to a branch anywhere, since there seems to be a fair bit of work to apply it to trunk?

Proper multiple monitor support is planned for 0.4. Currently most of the foundations for this should be in place, someone needs to sit down and deal with the specifics of implementing it before release day of course

Yet another bug confirmation. I have two monitors: 1680x1050 (left, 150 pixels down) and 1920x1200 (right). The bottom of the screens are flush with each other. The top left black area is not used/visible.

Please post to this bug thread when the multi-monitor code has been worked on a bit. I'll test it out and report what I find.

Section "Screen"
    Identifier "Screen0"
    Device "Videocard0"
    Monitor "Monitor0"
    DefaultDepth 24
    Option "TwinView" "1"
    Option "TwinViewXineramaInfoOrder" "DFP-1"
    Option "metamodes" "DFP-0: nvidia-auto-select +0+150, DFP-0: nvidia-auto-select +1680+0"
EndSection

Could you test this with our latest Awn-testing packages, please?
http://wiki.awn-project.org/DistributionGuides#Testing_Package_Archive

No joy with current testing packages. Are there meant to be some configuration options to deal with this? Like, an option to choose which monitor to display on?

At least with the testing packages the position is dynamically honored by using the force_monitor settings, but this doesn't change the screen reservation location, and means running a script to update the position (and perform mathematics) based on what monitors are connected.

I'm using the latest PPA trunk build with Twin-View and I'm able to move the AWN bar to any screen/side correctly. It seems to be fixed.

This bug was fixed in the package avant-window-navigator - 0.4.0~rc1-0ubuntu1

---------------
avant-window-navigator (0.4.0~rc1-0ubuntu1) lucid; urgency=low

  * New upstream release (0.4.0 rc1) (LP: #542684)
   - Ensure the autostart exist before trying to delete it.
     (LP: #334454)
   - Fix position with multiple screen. (LP: #248769)
  * debian/control:
   - Move awn-settings to depends, to ensure migration from awn-manager.
     (LP: #512411)
  * debian/patches/01-require-lda.patch : Only require 0.0.1 version of lda.
  * debian/libawn1.symbols: Add missing symbol.
 -- Julien Lavergne <email address hidden> Tue, 23 Mar 2010 00:24:44 +0100