xfce4-panel bug

Olivier Fourdan fourdan at xfce.org
Sun Feb 23 15:30:06 CET 2003


Jasper,

On Sun, 2003-02-23 at 15:18, Jasper Huijsmans wrote:
> err, I don't follow completely. Does this mean a program cannot set
> itself in the strut area of another program? 
> 
> This would mean the margins code could be moved to the panel. Am I
> right? This kinda sucks, because then I couldn't put the panel in line
> with gkrellm anymore, for instance.
> 
> Or is it only for the top of the screen?

It's only for the top of the screen. For the other sides, only decorated
windows are constrained within the struts area.

> Also, I don't know if this is still the case, xfwm doesn't seem to take
> the panel into account when positioning other windows. Because that
> would go a long way to solve the margins problem, if other windows
> would not normally cover the panel area, unless there is limited space
> or an application specifically requestst to do so.

The code in xfwm4 that computes overlapping says, "c" being the client
to "c2" being any of the other clients :

if((c2 != c) && (c2->type != WINDOW_DESKTOP) && (c->win_workspace ==
c2->win_workspace) && CLIENT_FLAG_TEST(c2, CLIENT_FLAG_VISIBLE))

In other words, is taken into account any window that is visible, on the
same workspace and that is not a desktop window.

I don't see why the panel would not be taken into account (and actually
I can tell it is taken into account like any other client). That said,
the algorithm tests all positions on screen and computes the total
overlapping of windows for each positions, and returns the position that
has the lower overlapping value. That doesn't mean that the panel cannot
be covered.

Cheers,
-- 
Olivier Fourdan <fourdan at xfce.org>
http://www.xfce.org




More information about the Xfce4-dev mailing list