bugGNUstep - Bugs: bug #24083, Offset issues with the xmonad WM

Group
 
 

bug #24083: Offset issues with the xmonad WM

Submitter:  Yavor Doganov <yavor>
Submitted:  Sat 16 Aug 2008 07:41:26 PM UTC
   
 
Category:  Backend Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 22 May 2009 06:23:54 PM UTC, comment #13: 

Fred -- sorry for the delay.  The OP reports this is fixed in 0.16.0, so please close.  Thanks!

Yavor Doganov <yavor>
Fri 30 Jan 2009 10:25:46 PM UTC, comment #12: 

Changed the state of this bug report to testing as there was a fix and no feedback since then.

Fred Kiefer <FredKiefer>
Group Member
Sun 30 Nov 2008 09:30:11 PM UTC, comment #11: 

Does the border issue for xmonad still persist? There was another change to the way we handle window offsets and perhaps this solves this problem was well. Could you get your user to try it with GNUstep gui from SVN trunk?

Fred Kiefer <FredKiefer>
Group Member
Mon 08 Sep 2008 07:31:04 PM UTC, comment #10: 

Removed the cairo part from the summary as this is resolved.

Fred Kiefer <FredKiefer>
Group Member
Wed 27 Aug 2008 08:45:45 AM UTC, comment #9: 

Many thanks...
The OP confirmed that the NSBezierPath.m patch resolves the problem with cairo, so this bug remains for the (minor) xmonad issue.

Yavor Doganov <yavor>
Fri 22 Aug 2008 07:51:00 PM UTC, comment #8: 

I investigated the matter further and found the cairo backend to be broken with gui <= rev 26815 on 64bit machines, since 26816 rendering is okay for me again. So apparently the change in NSBezierPath.m did the trick. I guess I've just been missing a few (curcial) revisions.
Thank you for pointing me into the right direction with this issue!

Cheers,

Niels

Niels Grewe <thebeing>
Group Member
Fri 22 Aug 2008 06:15:28 PM UTC, comment #7: 

For what it's worth, apps look fine running with the current cairo backend from svn trunk on my system ... which is intel 64bit running debian unstable.
As far as versioning goes, looking at the backend bundle, I see it's linked with libcairo.so.2 and it looks like my current installed version of libbcairo-dev is 1.6.4


Richard Frith-Macdonald <CaS>
Group Member
Fri 22 Aug 2008 05:48:35 PM UTC, comment #6: 

It really would be best to split of this bug report into two. Otherwise we always need to state, which of the two issues (xmonad, cairo) we are talking about.

Cairo:
In back 0.14 the check for cairo 1.6 is a compile time check, since then I adjusted it to be a runtime check, but no new GNUstep release was posted after that change.
If the backend was compiled for an older cairo release you should get black borders in all windows. But as far as I understand the original bug report, this is not what you get.

Is the problem that on a 64 bit system the whole window stays blank with the cairo backend?

Richard just made a correction in gui for 64 bit system, that could affect all drawing, could you please use latest trunk to verify that your problem still exists?

On the other side, is anybody successfully using the cairo backend on a 64 bit system? My problem here is that I don't use a system, where I could test this myself.

Fred Kiefer <FredKiefer>
Group Member
Fri 22 Aug 2008 11:59:19 AM UTC, comment #5: 

Hello,
I'm also using GNUstep on Debian unstable (that means cairo v1.6.4, base 1.16.3 and back 0.14.0) and am experiencing the exact same problems with the cairo backend (art works like a charm), both when using GNUstep from the Debian repository and when compiling from trunk. The bug occurs regardless of X-server or window-manager, but I have so far only been able to reproduce it under the amd64/x86_64 architecture, not on 32bit systems. So I'm guessing that this might be implicated in this bug.
If there is any further testing/posting debug-logs that would be helpfull, I would be glad to help out.

best regards


Niels

Niels Grewe <thebeing>
Group Member
Tue 19 Aug 2008 08:17:33 PM UTC, comment #4: 


> I will need to know which version of cairo and
> of GNUstep are being used.


Based on his Debian suite, they are:

cairo 1.6.4
Base 1.16.1
Gui/Back 0.14.0

Yavor Doganov <yavor>
Tue 19 Aug 2008 07:45:59 PM UTC, comment #3: 

So there are two issues. One with the cairo backend and one with the xmonad interaction.

For the cairo backend issue I will need to know which version of cairo and of GNUstep are being used.

For the other problem I may need to explain first, why GNUstep tries to determine the window border. In OpenStep it is possible to position the contents of a window as well as the window itself, to do this reliable we need to know about the border of the window. It even goes as far as positioning an unmapped window, where we cannot determine the current border. That is why we try to find out about standard windows borders when GNUstep starts up.

For most modern window managers we have code to do this, perhaps we need to add an extra bit for window managers that don't reparent a window. Here we only get ConfigureNotify events (#22 in the log you send), perhaps we could just rely on the border width given there.

Fred Kiefer <FredKiefer>
Group Member
Tue 19 Aug 2008 07:37:09 AM UTC, comment #2: 

I've never used xmonad, I just installed it to test this particular problem.  Here is what the OP replied:

"I have no idea what business has GNUstep with window borders. The application draws into its window and the window location on the screen and decorations are the business of the window manager.

Just set the offsets to 0 when the windows are not reparented, and if somebody complains they can get the them calculated properly. With typical configuration you would be at most one pixel off even if the value was actually useful for something."

The default window border size for xmonad is 1, it seems.

The grey windows with the cairo backend are unrelated to xmonad -- the OP says he gets the same behavior with Window Maker.  Any clues what might be the cause?  His machine is amd64 (aka x86_64), FWIW.

Yavor Doganov <yavor>
Mon 18 Aug 2008 09:58:27 PM UTC, comment #1: 

The log file looks like xmonad does not reparent windows, that way GNUstep fails to compute any window border size and guesses them (wrongly of course). Most likely they should all be 0.

But this should not result in an all black (or gray, as the original report states) window, rather I would expect some black borders.

Do you know of any way to find out about the selected window borders with xmonad? That is about the only thing I could think of doing in relation to this bug report. You state yourself that the original problem is not reproducable for you.

Fred Kiefer <FredKiefer>
Group Member
Sat 16 Aug 2008 07:41:26 PM UTC, original submission:  

A Debian user reported at <http://bugs.debian.org/495373> that with xmonad WM and the cairo backend he gets blank windows, very similar to the issue reported for IceWM in bug #21571.

I can't reproduce it, although like him I get "styleoffsets ... guessing offsets" on the console.

His configuration:
screen #0:
  dimensions:    1280x1024 pixels (338x271 millimeters)
  resolution:    96x96 dots per inch
  depths (7):    24, 1, 4, 8, 15, 16, 32
  root window id:    0x7f
  depth of root window:    24 planes

No special effects, compositing manager, etc.
Attached is his log with `--GNU-Debug=Offset'.

Yavor Doganov <yavor>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #16301:  offset-log added by yavor (39KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by thebeing (Posted a comment)
  • -email is unavailable- added by FredKiefer (Posted a comment)
  • -email is unavailable- added by yavor (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-05-23 FredKiefer StatusReady For Test Fixed
        Open/ClosedIn Test Closed
    2009-01-30 FredKiefer StatusNone Ready For Test
        Open/ClosedOpen In Test
    2008-09-08 FredKiefer SummaryOffset issues with the xmonad WM; blank windows with the cairo backend Offset issues with the xmonad WM
    2008-08-16 yavor Attached File- Added offset-log, #16301

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code