Ticket #5 (defect)

I believe the problem is that the notification windows are not xinerama aware? I have two 1024x768 monitors and notifications will spread over the two, rendering them unreadable.

This patch fixes it nicely for me. I'm not sure that it's completely equivalent though.

I have an extra problem with this. I have two 17" crt's each 1280x1024 but sometimes it's just overkill to use both of them (i.e. when I'm slacking, not working), so I turn off the one on the right and use only the left one. Most apps work ok with this, because window positioning is done by the wm, but as notification-daemon forces a position, all notifications end up on the right screen (turned off) and not on the left (on).

Couldn't this be changed so notifications will appear on the screen the mouse is, as the wm does it?

Definitely, and that's how I'd like to see this implemented. I've been busy with other projects, but I want the next version of notification-daemon to implement it this way.

The problem with the patch supplied is that it doesn't take into account the space occupied by panels. This needs to know the "work area" of each monitor. Unfortunately, there is no current way of doing this using the standard X atoms or glib functions. The only way to really do this is to iterate through all the open windows and compute the work areas the way a window manager would, which is a lot of extra work and I'm not sure how efficient it would be to do this every time a notification is displayed. But, it needs to be done.. Anyone want to work on a patch? :)

There's some rough code in SVN now to structure things in a multi-monitor environment. We're just missing the X support.

no 100% related but fits into to topic, on dual-head conf, the bubble attached to notification area icons can overlap on the second head which is inconvenient to read the info on regular displays. I think the bug for this resides in libnotify.

I've had exactly the same problem: the monitor on the right is smaller than the (primary) mointor on the left, and the notifiation "bubbles" are hidden in the "blind spot" at the bottom right corner.

However, I've added an extra panel at the bottom of the smaller mointor (right click on existing panel, choose "New panel", drag new panel to bottom of smaller monitor), and the previously hidden notifications are now visible! :)

Looks like the panel effectively defines the "bottom" of the visible area. You can set the panel to "auto-hide" if it takes up too much space, the technique will still work.

These are basicly two bugs: 1. Notifications are drawn at the wrong position on multihead setups when using vertical panels or different monitor resolutions. 2. Notifications with arrows do cross the monitor frame on multi-head setups.

As previously discussed, I have given my shot at this patch, as it's long overdue, which turned out an issue in the overall Xorg/GTK+ combo which does not allow retrieving the workarea in an easy way when it comes to multihead.

Currently the workspace is retrieved by reading the _NET_WORKSPACE hint on the root window, however that one does not give you information per monitor or about panels which are inbetween monitors. I think the WM spec could need some fix for multihead here.

The idea was to do what a window manager would do, which certainly is overhead for a small daemon displaying notifications.

I attached an "prototype" patch for issue 1) which has some nifty custom gdk_screen_get_monitor_workarea() doing the dirty work. It seems to work great here as far as I tested and fixes all issues noted. Any changes to panels are directly reflected in the drawing and each monitor is drawing it's own notification stack.

Depending on the performance impact, it might be more pleasing to get the workarea once when creating all stacks for the monitors and store it in the NotifyStack? struct. If we make the daemon auto-exit if no notifications are being drawn (as it is respawned by dbus), it could make sure we update the workarea appropriately. Otherwise, I don't currently know how an event/callback based approach to listen for panel changes would look like (which certainly would be the most efficient).

Outstanding testing should be done on single-head, multiple X Screen setups, maybe KDE and cleaning up my code.

I also started to fix issue 2) which looks easy to fix in the theme drawing code but the patch is yet to be tested and thus pending.

Make standard theme only draw notifications within monitor geometry; fixes overlap

Ok, using it for almost two months without any issues on various systems. The code does not seem to have the performance impact which I thought it would have. Infact it's hardly noticeable at all so that might be a good thing.

Thanks for testing it. I haven't had a dual-head setup I could really work with it on lately (one of my LCDs needs to go in for repairs).

I'll be making this a part of the upcoming release. The release is going to be awesome :)

I applied the fix for the arrows.

There appears to be a problem on single-head setups at least where the very first notification covers part of the panel. The strip does not render there, but everything else does. Have you seen this?

Also, can you make this so it doesn't require a C99-compliant compiler? Removing nested functions and initializing all variables up-front.

Okay, last comment before I sleep.

The test program I used to reproduce that bug was test-basic. test-multi-actions also does it. The second notification is always correct.

Ok, going to check out the issue and fix C99 compliance stuff.

Add per monitor workarea discovery and notifications stack drawing (v2)

- I (hopefully) fixed the C99 compliance requirement. Not that good at that so please check.

- The positioning issue with the first notification is caused due to gtk_widget_size_request() returning a wrong (?) size for the first notification in notify_stack_add_window() ONLY on single-head (???).

This seems to exist in prior versions (before my patches) aswell. Just printf that req.height and you'll notice the wrong size and the first notification to be wrongly positioned. Not sure yet what is causing this, but at least it's does not seem to be in this patch (I manually corrected the size and everything works).

- I can not reproduce the missing stripe issue (single/dual-head, not-/composited, intel/nvidia-binary). Assuming it is related with the incorrect widget size returned from gtk_widget_size_request() could explain the rendering/drawing glitch.

Now the question is what is happening there...