Re: Patch: Partial support for partial struts

[BALATON Zoltan]

On Wed, 31 Oct 2012, Carlos R. Mafra wrote:

My first impression is that wArrangeIcons() should be called
when appicons are removed (because they can leave a hole).
But when they are created, why do we care? Aren't they simply
supposed to be appended (eg to the right) of the existing
appicons?


I'm not completely sure about that but I think Auto-arrange icons also 
makes sure that app icons and miniwindows are not mixed together but 
appicons precede miniwindows. This means that miniwindows may need to be 
shifted if a new appicon is created and also when removed. Does that make 
sense?


Regards,
BALATON Zoltan


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

Re: Patch: Partial support for partial struts

[Carlos R. Mafra]

First of all: thanks for doing this, Iain!

On Tue, 30 Oct 2012 at  5:29:46 +, Iain Patterson wrote:

 Subject: [PATCH 1/3] AppIcon helper functions.
 
 Create wAppIconFor() and wAppIconTouchesHead() to match wWindowFor()
 and wWindowTouchesHead().  These functions will allow us to locate the
 window and head associated with a particular app icon or dock icon.

 +WAppIcon *wAppIconFor(Window window)
 +{
 + WObjDescriptor *desc;
 +
 + if (window == None)
 + return NULL;
 +
 + if (XFindContext(dpy, window, wWinContext, (XPointer *)  desc) == 
 XCNOENT)
 + return NULL;
 +
 + if (desc-parent_type == WCLASS_APPICON || desc-parent_type == 
 WCLASS_DOCK_ICON)
 + return desc-parent;
 +
 + return NULL;
 +}

Perhaps it's just me, but I can't really get what the function does
from just reading its name: wAppIconFor(). I'm no native speaker, but
the For suffix confuses me. I wonder if wAppIconOf() would be more
correct -- ignoring the CamelCase issue :-)

I think there is a better name which clearly states its purpose.
I'm bad in choosing names, though.

I guess that justifies having some comment on top of the function
to state its purpose? I know it's a small function, but I find it
nicer to have an overview of what the function is supposed to do
before reading it.


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

Re: Patch: Partial support for partial struts

[kix]

On 2012-10-30 16:42, Carlos R. Mafra wrote:

First of all: thanks for doing this, Iain!

On Tue, 30 Oct 2012 at  5:29:46 +, Iain Patterson wrote:


Subject: [PATCH 1/3] AppIcon helper functions.

Create wAppIconFor() and wAppIconTouchesHead() to match wWindowFor()
and wWindowTouchesHead().  These functions will allow us to locate 
the

window and head associated with a particular app icon or dock icon.



+WAppIcon *wAppIconFor(Window window)
+{
+   WObjDescriptor *desc;
+
+   if (window == None)
+   return NULL;
+
+	if (XFindContext(dpy, window, wWinContext, (XPointer *)  desc) == 
XCNOENT)

+   return NULL;
+
+	if (desc-parent_type == WCLASS_APPICON || desc-parent_type == 
WCLASS_DOCK_ICON)

+   return desc-parent;
+
+   return NULL;
+}


Perhaps it's just me, but I can't really get what the function does
from just reading its name: wAppIconFor(). I'm no native speaker, but
the For suffix confuses me. I wonder if wAppIconOf() would be more
correct -- ignoring the CamelCase issue :-)


This is used in other functions. I don't have wmaker source here, but 
the prototype is something like:


wAppIconFor(WWindow *wwin)

then you can read it as:

AppIcon for wwindow :-)

I don't like these function names!

I am changing the camel case too, we can see the code modified :-)

CamelCase: Original code
no_camel_case: New code :-P


I think there is a better name which clearly states its purpose.
I'm bad in choosing names, though.


I have a lot of monkeys typing here ;-)


I guess that justifies having some comment on top of the function
to state its purpose? I know it's a small function, but I find it
nicer to have an overview of what the function is supposed to do
before reading it.


Cheers,
kix
--
||// //\\// Rodolfo kix Garcia
||\\// //\\ http://www.kix.es/


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

Re: Patch: Partial support for partial struts

[Iain Patterson]

Quoth Carlos R. Mafra,


Perhaps it's just me, but I can't really get what the function does
from just reading its name: wAppIconFor(). I'm no native speaker, but
the For suffix confuses me. I wonder if wAppIconOf() would be more
correct -- ignoring the CamelCase issue :-)


  You're probably right.  I chose the name to match the existing 
function wWindowFor() since it does a similar thing.



I think there is a better name which clearly states its purpose.
I'm bad in choosing names, though.


  Function names are all over the place.  We have some in Camel case, 
some all lowercase and I'm not sure of the logic behind some starting 
with the w prefix and others not.


  A more general discussion on naming may be worthwhile.  I'm happy 
to change the name of the new function to something which we can agree 
on.  If I change it, though, I think I should change wWindowFor() as 
well.  Or even everything (mwahahaha!)...



I guess that justifies having some comment on top of the function
to state its purpose? I know it's a small function, but I find it
nicer to have an overview of what the function is supposed to do
before reading it.


  No problem, and again if wAppIconFor() needs a comment then 
wWindowFor() does too.
From 8d696a3776c2b7df4316232ae31cf3be39ec0dc9 Mon Sep 17 00:00:00 2001
From: Iain Patterson w...@iain.cx
Date: Tue, 30 Oct 2012 09:10:14 -0700
Subject: [PATCH] Brief documentation on wAppIconFor() and wWindowFor().

Brief comment on what wAppIconFor() and wWindowFor() do, as it
may not be immediately obvious.

Given a raw X11 Window they will find the AppIcon (or WWindow,
respectively) associated with that window.  Thus they can map an
X11 object to a Window Maker internal object.
---
 src/appicon.c | 1 +
 src/window.c  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/src/appicon.c b/src/appicon.c
index 5d654de..cc2f7d8 100644
--- a/src/appicon.c
+++ b/src/appicon.c
@@ -1021,6 +1021,7 @@ static void remove_from_appicon_list(WScreen *scr, 
WAppIcon *appicon)
appicon-next = NULL;
 }
 
+/* Return the AppIcon associated with a given (Xlib) Window. */
 WAppIcon *wAppIconFor(Window window)
 {
WObjDescriptor *desc;
diff --git a/src/window.c b/src/window.c
index 4691021..199613c 100644
--- a/src/window.c
+++ b/src/window.c
@@ -141,6 +141,7 @@ static void appearanceObserver(void *self, WMNotification * 
notif)
 }
 
 
+/* Return the WWindow associated with a given (Xlib) Window. */
 WWindow *wWindowFor(Window window)
 {
WObjDescriptor *desc;
-- 
1.7.11.4

Re: Patch: Partial support for partial struts

[Carlos R. Mafra]

On Tue, 30 Oct 2012 at  9:14:34 -0700, Iain Patterson wrote:
 Subject: [PATCH] Brief documentation on wAppIconFor() and wWindowFor().
 
 Brief comment on what wAppIconFor() and wWindowFor() do, as it
 may not be immediately obvious.
 
 Given a raw X11 Window they will find the AppIcon (or WWindow,
 respectively) associated with that window.  Thus they can map an
 X11 object to a Window Maker internal object.

Lovely.

Thanks a lot, Iain!


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

Re: Patch: Partial support for partial struts

[Iain Patterson]

Quoth Carlos R. Mafra,

The patches are going to be applied, they are very cool and have
a lot of potential.


  Ironically I have been a little counterproductive to myself 
(hopefully not to users in general) with this work.


  I like Window Maker for many reasons but its use of app icons is 
not among them.  I don't like icons on my desktop and I just find they 
get in the way.  On my (small screen) laptop I have no dock and the 
icons set to 24x24 arranged at the top of the screen.  I then run 
xfce4-panel set to a height 24 at the top and it covers the icons.  By 
setting don't cover icons I could ensure that maximisation didn't 
clash with the panel and I'd never have to see them again.


  My desktop has normal 64x64 icons down the side of the screen where 
I can mostly ignore them.  I found that windows would try to place 
under the panel, which was annoying.  Now with partial strut support 
the panel is protected and life is good on the desktop.  Back on the 
laptop the icons now refuse to hide under the panel because they 
respect its strut.


  I can think of two possible solutions.  Either add a preference to 
make icons ignore struts and go wherever they like or add a preference 
to refrain from placing icons at all.  Does anyone else share my 
dislike of desktop clutter and have an opinion either way?



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

Re: Patch: Partial support for partial struts

[Carlos R. Mafra]

On Tue, 30 Oct 2012 at  9:42:05 -0700, Iain Patterson wrote:
 Quoth Carlos R. Mafra,
 The patches are going to be applied, they are very cool and have
 a lot of potential.
 
   Ironically I have been a little counterproductive to myself
 (hopefully not to users in general) with this work.
 
   I like Window Maker for many reasons but its use of app icons is
 not among them.  I don't like icons on my desktop and I just find
 they get in the way.  On my (small screen) laptop I have no dock and
 the icons set to 24x24 arranged at the top of the screen.  I then
 run xfce4-panel set to a height 24 at the top and it covers the
 icons.  By setting don't cover icons I could ensure that
 maximisation didn't clash with the panel and I'd never have to see
 them again.
 
   My desktop has normal 64x64 icons down the side of the screen
 where I can mostly ignore them.  I found that windows would try to
 place under the panel, which was annoying.  Now with partial strut
 support the panel is protected and life is good on the desktop.
 Back on the laptop the icons now refuse to hide under the panel
 because they respect its strut.
 
   I can think of two possible solutions.  Either add a preference to
 make icons ignore struts and go wherever they like or add a
 preference to refrain from placing icons at all.  Does anyone else
 share my dislike of desktop clutter and have an opinion either way?

I don't remember what happened to the patch in that thread, but
take a look at how to disable appicons here:

http://article.gmane.org/gmane.compw.window-managers.windowmaker.devel/1209/match=option+disable+application+icons


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

Re: Patch: Partial support for partial struts

[Iain Patterson]

  The attached patches make icons and the dock declare their own 
partial struts if the do not cover preferences are active.


  The actual user experience should remain the same until we can 
revamp screen usable area.  I have a few ideas for that...
From a60c65ce086bebaa312cb996748dce78ef1a4995 Mon Sep 17 00:00:00 2001
From: Iain Patterson w...@iain.cx
Date: Mon, 29 Oct 2012 15:35:56 -0700
Subject: [PATCH 1/3] AppIcon helper functions.

Create wAppIconFor() and wAppIconTouchesHead() to match wWindowFor()
and wWindowTouchesHead().  These functions will allow us to locate the
window and head associated with a particular app icon or dock icon.
---
 src/appicon.c  | 17 +
 src/appicon.h  |  1 +
 src/xinerama.c | 19 +++
 src/xinerama.h |  2 ++
 4 files changed, 39 insertions(+)

diff --git a/src/appicon.c b/src/appicon.c
index 9bac0ef..6be3057 100644
--- a/src/appicon.c
+++ b/src/appicon.c
@@ -60,6 +60,7 @@
 extern Cursor wCursor[WCUR_LAST];
 extern WPreferences wPreferences;
 extern WDDomain *WDWindowAttributes;
+extern XContext wWinContext;
 
 #define MOD_MASK   wPreferences.modifier_mask
 
@@ -1016,3 +1017,19 @@ static void remove_from_appicon_list(WScreen *scr, WAppIcon *appicon)
 	appicon-prev = NULL;
 	appicon-next = NULL;
 }
+
+WAppIcon *wAppIconFor(Window window)
+{
+	WObjDescriptor *desc;
+
+	if (window == None)
+		return NULL;
+
+	if (XFindContext(dpy, window, wWinContext, (XPointer *)  desc) == XCNOENT)
+		return NULL;
+
+	if (desc-parent_type == WCLASS_APPICON || desc-parent_type == WCLASS_DOCK_ICON)
+		return desc-parent;
+
+	return NULL;
+}
diff --git a/src/appicon.h b/src/appicon.h
index a6c6a6a..6f72c8e 100644
--- a/src/appicon.h
+++ b/src/appicon.h
@@ -83,4 +83,5 @@ void paint_app_icon(WApplication *wapp);
 void unpaint_app_icon(WApplication *wapp);
 void wApplicationExtractDirPackIcon(WScreen * scr, char *path, char *wm_instance,
 char *wm_class);
+WAppIcon *wAppIconFor(Window window);
 #endif
diff --git a/src/xinerama.c b/src/xinerama.c
index 823df99..4bd9ca4 100644
--- a/src/xinerama.c
+++ b/src/xinerama.c
@@ -201,6 +201,25 @@ Bool wWindowTouchesHead(WWindow * wwin, int head)
 	return (a != 0);
 }
 
+Bool wAppIconTouchesHead(WAppIcon * aicon, int head)
+{
+	WScreen *scr;
+	WMRect rect;
+	int a;
+
+	if (!aicon || !aicon-icon)
+		return False;
+
+	scr = aicon-icon-core-screen_ptr;
+	rect = wGetRectForHead(scr, head);
+	a = calcIntersectionArea(aicon-x_pos, aicon-y_pos,
+ aicon-icon-core-width,
+ aicon-icon-core-height,
+ rect.pos.x, rect.pos.y, rect.size.width, rect.size.height);
+
+	return (a != 0);
+}
+
 int wGetHeadForWindow(WWindow * wwin)
 {
 	WMRect rect;
diff --git a/src/xinerama.h b/src/xinerama.h
index 0699726..fd1d469 100644
--- a/src/xinerama.h
+++ b/src/xinerama.h
@@ -21,6 +21,7 @@
 #ifndef _WMXINERAMA_H_
 #define _WMXINERAMA_H_
 
+#include appicon.h
 #include screen.h
 #include window.h
 #include WINGs/WINGs.h
@@ -51,6 +52,7 @@ WArea wGetUsableAreaForHead(WScreen *scr, int head, WArea *totalAreaPtr, Bool no
 WMPoint wGetPointToCenterRectInHead(WScreen *scr, int head, int width, int height);
 
 Bool wWindowTouchesHead(WWindow *wwin, int head);
+Bool wAppIconTouchesHead(WAppIcon *aicon, int head);
 
 #endif
 
-- 
1.7.11.7

From be318a0cde7bf3c13f1545743bb0671f8d66d599 Mon Sep 17 00:00:00 2001
From: Iain Patterson w...@iain.cx
Date: Mon, 29 Oct 2012 15:49:43 -0700
Subject: [PATCH 2/3] Allow struts from all windows.

Respect _NET_WM_STRUT and _NET_WM_STRUT_PARTIAL from all windows, not
just WWindows.  This will allow us to respect struts from app icons
and dock icons.
---
 src/wmspec.c | 29 +
 1 file changed, 13 insertions(+), 16 deletions(-)

diff --git a/src/wmspec.c b/src/wmspec.c
index 4ca8af4..6bd51ce 100644
--- a/src/wmspec.c
+++ b/src/wmspec.c
@@ -845,24 +845,21 @@ static void updateStateHint(WWindow *wwin, Bool changedWorkspace, Bool del)
 	}
 }
 
-static Bool updateStrut(WWindow *wwin, Bool adding)
+static Bool updateStrut(WScreen *scr, Window w, Bool adding)
 {
-	WScreen *scr;
 	WReservedArea *area;
 	Bool hasState = False;
 
-	scr = wwin-screen_ptr;
-
 	if (adding) {
 		Atom type_ret;
 		int fmt_ret;
 		unsigned long nitems_ret, bytes_after_ret;
 		long *data = NULL;
 
-		if ((XGetWindowProperty(dpy, wwin-client_win, net_wm_strut, 0, 4, False,
+		if ((XGetWindowProperty(dpy, w, net_wm_strut, 0, 4, False,
    XA_CARDINAL, type_ret, fmt_ret, nitems_ret,
    bytes_after_ret, (unsigned char **)data) == Success  data) ||
-		((XGetWindowProperty(dpy, wwin-client_win, net_wm_strut_partial, 0, 12, False,
+		((XGetWindowProperty(dpy, w, net_wm_strut_partial, 0, 12, False,
    XA_CARDINAL, type_ret, fmt_ret, nitems_ret,
    bytes_after_ret, (unsigned char **)data) == Success  data))) {
 
@@ -879,7 +876,7 @@ static Bool updateStrut(WWindow *wwin, Bool adding)
 			area-area.y1 = data[2];
 			area-area.y2 = data[3];
 
-			area-window = wwin-client_win;
+			

Re: Patch: Partial support for partial struts

[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: Partial support for partial struts

[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.

Patch: Partial support for partial struts

[Iain Patterson]

  I noticed that the top of maximized windows got hidden underneath 
xfce4-panel.
From bd1a23fb0d9899d0b75a322d4d8eb853a2b4fc62 Mon Sep 17 00:00:00 2001
From: Iain Patterson w...@iain.cx
Date: Fri, 26 Oct 2012 11:40:55 -0700
Subject: [PATCH] Partially support _NET_WM_STRUT_PARTIAL.

Window Maker already supports the _NET_WM_STRUT property as described
in the EWMH spec.  We respect client-provided struts and avoid placing
or maximizing windows over those areas.  An example is that we don't
try to place or maximize windows where they would be obscured by an
always-on-top gnome-panel.

_NET_WM_STRUT is now deprecated and redefined as a special case of
_NET_WM_STRUT_PARTIAL, which allows variable strut widths.  A panel at
the bottom of the screen, for example, does not have to reserve the
whole width as a strut if it does not fill 100% of the screen width.
By default the XFCE bottom panel does not extend the whole width of
the screen, for instance.

Our method for restricting parts of the screen from placement doesn't
have a way to account for struts which are not 100% tall or 100% wide,
so until now we have ignored partial struts.  In the case of the XFCE
panel mentioned above, the result is that a window may maximize
underneath the panel and be obscured.

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.
---
 src/wmspec.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/src/wmspec.c b/src/wmspec.c
index db3526f..a068642 100644
--- a/src/wmspec.c
+++ b/src/wmspec.c
@@ -862,10 +862,20 @@ static Bool updateStrut(WWindow * wwin, Bool adding)
unsigned long bytes_after_ret;
long *data = NULL;
 
-   if (XGetWindowProperty(dpy, wwin-client_win, net_wm_strut, 0, 
4, False,
+   if ((XGetWindowProperty(dpy, wwin-client_win, net_wm_strut, 0, 
4, False,
   XA_CARDINAL, type_ret, fmt_ret, 
nitems_ret,
-  bytes_after_ret, (unsigned char 
**)data) == Success  data) {
-
+  bytes_after_ret, (unsigned char 
**)data) == Success  data) ||
+   ((XGetWindowProperty(dpy, wwin-client_win, 
net_wm_strut_partial, 0, 12, False,
+  XA_CARDINAL, type_ret, fmt_ret, 
nitems_ret,
+  bytes_after_ret, (unsigned char 
**)data) == Success  data))) {
+
+   /* XXX: This is strictly incorrect in the case of 
net_wm_strut_partial...
+* Discard the start and end properties from the 
partial strut and treat it as
+* a (deprecated) strut.
+* This means we are marking the whole width or height 
of the screen as
+* reserved, which is not necessarily what the strut 
defines.  However for the
+* purposes of determining placement or maximization 
it's probably good enough.
+*/
area = (WReservedArea *) wmalloc(sizeof(WReservedArea));
area-area.x1 = data[0];
area-area.x2 = data[1];
@@ -1479,7 +1489,7 @@ Bool wNETWMCheckClientHintChange(WWindow * wwin, 
XPropertyEvent * event)
wmessage(clientHintChange type %s\n, XGetAtomName(dpy, event-atom));
 #endif
 
-   if (event-atom == net_wm_strut) {
+   if (event-atom == net_wm_strut || event-atom == net_wm_strut_partial) 
{
updateStrut(wwin, False);
updateStrut(wwin, True);
wScreenUpdateUsableArea(wwin-screen_ptr);
-- 
1.7.11.4