Philip Langdale | 8 May 04:07 2006
Picon

Initial patch to provided shaped input support

Hi all,

I spent more time today working on getting support for
windows with shaped input. Due to the way that the frame
window is assumed at many levels within sawfish, it is
not practical to take the metacity approach where the
window is not reparented. Instead, I've implemented it
by taking the client window's input shape and applying
that to the frame as well.

If the frame style is 'none', then the frame is exactly
the same size as the client and will now have exactly
the same input shape, which is what we want.

One subtlety is that I have, perhaps gratuitously, used
a little trick so that if there is a frame, the frame
still has input, even if the client does not; in practice,
input shaped windows will almost always not want a frame.

The method for detecting the use of input shaping is
clunky but unavoidable - XShapeQueryExtents was not
extended or supplemented to query input shaping, so I
call GetRectangles and if there is not exactly one rectangle,
we know shaping is in use. There is a pathological case of
one rectangle that is smaller than the window, but surely
the window should be shrunk to that size as well. This case
is not worth worrying about.

The patch is not final because it does not do compile time
or runtime checks for XShape 1.1. Things will not go well
(Continue reading)

Yoshiaki Kasahara | 8 May 05:06 2006
Picon

window-frame-offset weirdness on 64bit OS

Hello,

Recently I migrated from FreeBSD i386 to FreeBSD amd64, and noticed
that 'window-frame-offset' started to return extremely large values.
Due to that, 'warp-cursor-to-window' didn't work correctly.

% sawfish-client -e '(window-frame-offset (get-window-by-name-re "xconsole"))'
(1073741819 . 1073741802)

Actually these values are (0x3ffffffb . 0x3fffffea) in hex.

After some investigation, I noticed that frame_x and frame_y of struct
lisp_window were declared as 'u_int' in sawmill.h, but actually these
had negative values.  Changing them to 'int' fixed the problem.

% sawfish-client -e '(window-frame-offset (get-window-by-name-re "xconsole"))'
(-5 . -22)

Here is a small patch.

--- sawmill.h.orig      Mon Jan 13 05:35:23 2003
+++ sawmill.h   Thu May  4 00:52:59 2006
 <at>  <at>  -153,7 +153,7  <at>  <at> 
     /* Frame data */
     Window frame;
     struct frame_part *frame_parts;
-    u_int frame_x, frame_y;            /* relative to client-window */
+    int frame_x, frame_y;              /* relative to client-window */
     u_int frame_width, frame_height;
     void (*destroy_frame)(struct lisp_window *w);
(Continue reading)

John Harper | 16 May 08:37 2006

Re: window-frame-offset weirdness on 64bit OS


On May 7, 2006, at 8:06 PM, Yoshiaki Kasahara wrote:

> After some investigation, I noticed that frame_x and frame_y of struct
> lisp_window were declared as 'u_int' in sawmill.h, but actually these
> had negative values.  Changing them to 'int' fixed the problem.
>
> Here is a small patch.

thanks, I applied your patch,

>
> I'm using sawfish version 1.3 (+ get_x_property patch for 64bit OS)
> and librep 0.16.2 from FreeBSD Ports collection.

what is the get_x_property patch? Is it something that should be  
checked in to the main repository?

	John

John Harper | 16 May 08:53 2006

Re: Initial patch to provided shaped input support


On May 7, 2006, at 7:07 PM, Philip Langdale wrote:

> I spent more time today working on getting support for
> windows with shaped input. Due to the way that the frame
> window is assumed at many levels within sawfish, it is
> not practical to take the metacity approach where the
> window is not reparented. Instead, I've implemented it
> by taking the client window's input shape and applying
> that to the frame as well.

thanks, I merged in the changes from your patch. (plus "#ifdef  
ShapeInput" checks, so it should still build with older X releases.)

	John

Yoshiaki Kasahara | 16 May 08:55 2006
Picon

Re: window-frame-offset weirdness on 64bit OS

Hi,

On Mon, 15 May 2006 23:37:37 -0700,
	John Harper <jsh <at> unfactored.org> said:

> > Here is a small patch.
> 
> thanks, I applied your patch,

Thank you!

> > I'm using sawfish version 1.3 (+ get_x_property patch for 64bit OS)
> > and librep 0.16.2 from FreeBSD Ports collection.
> 
> what is the get_x_property patch? Is it something that should be  
> checked in to the main repository?

No.  It is already in the main repository.  Currently I'm using
sawfish-1.3 in FreeBSD Ports Collections (not CVS head).  I need a
patch for functions.c rev 1.99 in the main repository because I'm
using FreeBSD amd64, so I manually applied the patch extracted from
the main repository.  Sorry for the confusion.

I wonder when the next version of sawfish will be released...

Regards,
--

-- 
Yoshiaki Kasahara
kasahara <at> nc.kyushu-u.ac.jp

(Continue reading)

t takahashi | 31 May 02:41 2006
Picon

is this a sawfish bug?

is this a sawfish bug?

Bug#369635: kicker: "maximize all" fails to fully maximize   Inbox

  To: Debian Bug Tracking System <submit <at> bugs.debian.org>

...

i have kicker (kde panel with taskbar in it) set as follows.
i deleted ~/.kde before making changes.

       group tasks
       autohide immediately
       on top left
       custom size of 100 pixels
       classic style rather than elegant
       analog clock
       one dockapp running
       no launchers
       hide button on left
       no animation

otherwise pretty much default.

what i want is full maximization of all windows when i maximize them.
i also want panel being on top when i move the mouse to the top edge.

but when i use the right-click menu "maximize all" on a firefox group,
all windows are maximized up to where the panel would be.

(Continue reading)


Gmane