Re: Patch: Partial support for partial struts

2012-10-27 Thread Iain Patterson

Quoth Carlos R. Mafra,

I guess that people using xinerama might be annoyed if the panel
on one screen makes the corresponding space on the other screen
unusable too.


  I believe that each head has its own reserved space.  If the panel
is in one head it shouldn't take up space on another head.


Having proper _NET_WM_STRUT_PARTIAL could be actually very cool if
wmaker's dock used it in order to tell windows which space it
actually occupies.


  The dock has its own code path and its own preference to toggle
whether or not it can be covered.  Both aspects could be handled with
struts, I suppose.


Right now I have a dock which does not occupy the whole right edge
of the screen. And yet, if I horizontally maximize a window placed
in a vertical position level where there is no more dock icons (ie
the space bellow the bottom dockapp) it does not completely
maximize horizontally.


  For the same reason that I labelled my patch as "partial" support.
Right now each head has its own usable area which is just a rectangle.
 Windows can place or maximise within that area.  When a window
declares a strut the area is shrunk so that it no longer intersects
the strut.

  That's guaranteed to work because the struts must be placed along
edges.  It's also good enough most of the time.  In your example it
may look "wrong" that the horizontally maximised window doesn't extend
to the edge of the screen but you'll be grateful that it doesn't if
you add more icons to your dock. And my XFCE panel can also grow to
accommodate more widgets.

  Still it could be worth doing for the benefit of people with large
screens and small docks.


Have you thought about how much more work would be required to
make wmaker respect the full partial strut specification?


  I did think about it while working on the struts.

  To support them, and handle your partially-populated
dock, we'd need to change how the reserved space works.  Rather than
have one placeable rectangle we'd have to find the best area which
avoids all struts on the head.  Perhaps we can borrow some logic from
one of the window managers which already supports them.

  When maximising we'd have to check if the chosen size intersects a
strut and shrink it if so.  Somewhat like how Maximusize picks the
biggest area it can find and shrinks it until it no longer conflicts
with other windows.


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.


Re: Patch: Partial support for partial struts

2012-10-27 Thread Carlos R. Mafra
On Fri, 26 Oct 2012 at 14:54:58 -0700, Iain Patterson wrote:
>   I noticed that the top of maximized windows got hidden underneath
> xfce4-panel.

> Subject: [PATCH] Partially support _NET_WM_STRUT_PARTIAL.
> 

> 
> As a partial hackaround we now query windows for _NET_WM_STRUT_PARTIAL
> but throw away the start and end co-ordinates, assuming instead that
> the struts are full-width/full-height.  This trades off a small amount
> of wasted placement space to avoid the case where windows can be
> partially obscured by panels, which can be particularly annoying if
> the panel is at the top and the victim's titlebar becomes hidden.

I guess that people using xinerama might be annoyed if the panel
on one screen makes the corresponding space on the other screen
unusable too.

Having proper _NET_WM_STRUT_PARTIAL could be actually very cool if
wmaker's dock used it in order to tell windows which space it
actually occupies.

Right now I have a dock which does not occupy the whole right edge of
the screen. And yet, if I horizontally maximize a window placed
in a vertical position level where there is no more dock icons 
(ie the space bellow the bottom dockapp) it does not completely
maximize horizontally.

Have you thought about how much more work would be required to
make wmaker respect the full partial strut specification?






-- 
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.


Re: [PATCH] Fixed incorrect attributes for XCreateWindow's attributes

2012-10-27 Thread Rodolfo García Peñas
On Thu, 25 Oct 2012, Iain Patterson escribió:

> Quoth Christophe,
> 
> >The code was setting some values in the window's attribute structure
> >which were not being used (missing the corresponding vmask flag) and
> >was setting some vmask bits without setting the corresponding
> >value in the structure.
> 
>   This patch breaks the frame extents stuff I submitted recently.
> With the patch and compton set to draw semi-opaque frame extents
> what actually happens is no window decorations are drawn and a bunch
> of BadDrawable errors are spewed to the console.
> 
>   After reverting the patch everything works again.

I have a question about it. 

After my proposed patch (see my yesterday's mail), I was testing it. I found a 
problem with the image, is not perfect in icons with title (is not bad, but is 
not perfect), and I changed some things:

if (image) {
if (icon->show_title)
theight = WMFontHeight(scr->icon_title_font);

getSize(icon->icon_win, &width, &height, &depth);

printf("Win size = %u,%u\n", width, height);

//this crash image = wIconValidateIconSize(image, 
wPreferences.icon_size - theight);
image = wIconValidateIconSize(image, wPreferences.icon_size);
x = (wPreferences.icon_size - image->width) / 2;
y = theight + (wPreferences.icon_size - theight - 
image->height) / 2;

RCombineArea(tile, image, 0, 0, image->width, image->height, x, 
y);
}

I try to change "wPreferences.icon_size" by "wPreferences.icon_size - theight". 
It works, but sometimes wmaker crash :-( I found that the problem is that the 
icon height is not ok, sometimes is bad:

Win sizeo = 36906368,0
wmaker(catchXError(startup.c:177)): warning: internal X error: BadDrawable 
(invalid Pixmap or Window parameter)
Request code: 14 X_GetGeometry
Request minor code: 0
Resource ID: 0x0
Error serial: 31538

And I have a lot of BadDrawable errors:

Tamaño = 1041326260,32660
wmaker(catchXError(startup.c:177)): warning: internal X error: BadDrawable 
(invalid Pixmap or Window parameter)
Request code: 14 X_GetGeometry
Request minor code: 0
Resource ID: 0x0
Error serial: 35963


I removed the Christophe's patch, trying to see if the problem is there, but 
no. Probably you are right, the Christophe's patch is not ok (I don't know), 
but I have other problems with BadDrawable errors.

What should we do with the getSize function? Why it is returning "0" as height?

Thanks
kix
-- 
||// //\\// Rodolfo "kix" Garcia
||\\// //\\ http://www.kix.es/


-- 
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.