Subject: StyleById

From: Olivier Chapuis <[email-masked]>
Date: Mon, 19 May 2003 03:01:38 +0200

Hello,

Attached to this msg 2 new cmds StyleById and DestroyStyleById.
StyleById applies styles to specific windows:

	Pick Style $[w.id] NoTitle, !Borders

DestroyStyleById can destroy such a style.

The implementation solve the pbs with the patch send by Craig Milo Rogers
a few weeks ago:
- When a window is "destroyed" the associated StyleById is destroyed
too (if not a new window can have the same id and the old style by
id is applied).
- No more ambiguity with the Style cmd as we have a new cmd.

I see no strong reason against this patch, but (as we are under
feature freeze) a vote against it. Any one?

By the way I've noted a problem with the DestroyStyle cmd:

- Start an xterm
- Style * SloppyFocus
- Style XTerm ClickToFocus
- DestroyStyle XTerm

Then, the xterm has ClickToFocus (need a recapture to get SloppyFocus).

Regards, Olivier
Index: add_window.c
===================================================================
RCS file: /home/cvs/fvwm/fvwm/fvwm/add_window.c,v
retrieving revision 1.346
diff -u -r1.346 add_window.c
--- add_window.c	18 May 2003 18:12:14 -0000	1.346
+++ add_window.c	19 May 2003 00:54:40 -0000
@@ -2997,6 +2997,13 @@
 		return;
 	}
 
+	{
+		char xid[20];
+
+		sprintf(xid, "0x%x", (unsigned int)FW_W(fw));
+		CMD_DestroyStyleById(NULL, NULL, xid); 
+	}
+
 	/****** check if we have to delay window destruction ******/
 
 	if ((Scr.flags.is_executing_complex_function ||
Index: commands.h
===================================================================
RCS file: /home/cvs/fvwm/fvwm/fvwm/commands.h,v
retrieving revision 1.36
diff -u -r1.36 commands.h
--- commands.h	3 Jan 2003 06:57:35 -0000	1.36
+++ commands.h	19 May 2003 00:54:40 -0000
@@ -60,6 +60,7 @@
 	F_DESTROY_MENU,
 	F_DESTROY_MENUSTYLE,
 	F_DESTROY_STYLE,
+	F_DESTROY_STYLE_BY_ID,
 	F_DFLT_COLORS,
 	F_DFLT_COLORSET,
 	F_DFLT_FONT,
@@ -137,6 +138,7 @@
 	STROKE_ARG(F_STROKE)
 	STROKE_ARG(F_STROKE_FUNC)
 	F_STYLE,
+	F_STYLE_BY_ID,
 	F_TEARMENUOFF,
 	F_THISWINDOW,
 	F_TITLE,
@@ -252,6 +254,7 @@
 void CMD_DesktopName(F_CMD_ARGS);
 void CMD_DesktopSize(F_CMD_ARGS);
 void CMD_Destroy(F_CMD_ARGS);
+void CMD_DestroyStyleById(F_CMD_ARGS);
 #ifdef USEDECOR
 void CMD_DestroyDecor(F_CMD_ARGS);
 #endif /* USEDECOR */
@@ -368,6 +371,7 @@
 void CMD_StrokeFunc(F_CMD_ARGS);
 #endif /* HAVE_STROKE */
 void CMD_Style(F_CMD_ARGS);
+void CMD_StyleById(F_CMD_ARGS);
 void CMD_TearMenuOff(F_CMD_ARGS);
 void CMD_ThisWindow(F_CMD_ARGS);
 void CMD_Title(F_CMD_ARGS);
Index: functable.c
===================================================================
RCS file: /home/cvs/fvwm/fvwm/fvwm/functable.c,v
retrieving revision 1.23
diff -u -r1.23 functable.c
--- functable.c	11 Mar 2003 08:54:44 -0000	1.23
+++ functable.c	19 May 2003 00:54:42 -0000
@@ -220,6 +220,10 @@
 	CMD_ENT("destroystyle", CMD_DestroyStyle, F_DESTROY_STYLE, 0, 0),
 	/* - Delete style defined using Style */
 
+	CMD_ENT("destroystylebyid", CMD_DestroyStyleById,
+		F_DESTROY_STYLE_BY_ID, 0, 0),
+	/* - Delete style defined using StyleById */
+
 	CMD_ENT("direction", CMD_Direction, F_DIRECTION, 0, 0),
 	/* - Operate on the next window in the specified direction */
 
@@ -573,6 +577,9 @@
 #endif /* HAVE_STROKE */
 	CMD_ENT("style", CMD_Style, F_STYLE, 0, 0),
 	/* - Set attributes of windows that match a pattern */
+
+	CMD_ENT("stylebyid", CMD_StyleById, F_STYLE, 0, 0),
+	/* - Set attributes of a window using its X id */
 
 	CMD_ENT("tearmenuoff", CMD_TearMenuOff, F_TEARMENUOFF, 0, 0),
 	/* - Convert a menu to a window, for use as a menu command */
Index: fvwm.h
===================================================================
RCS file: /home/cvs/fvwm/fvwm/fvwm/fvwm.h,v
retrieving revision 1.220
diff -u -r1.220 fvwm.h
--- fvwm.h	2 Jan 2003 12:01:18 -0000	1.220
+++ fvwm.h	19 May 2003 00:54:45 -0000
@@ -547,6 +547,7 @@
 	struct window_style *next;
 	struct window_style *prev;
 	char *name;
+	XID xid;
 #if 0
 	WindowConditionMask *condition_mask;
 #endif
Index: style.c
===================================================================
RCS file: /home/cvs/fvwm/fvwm/fvwm/style.c,v
retrieving revision 1.208
diff -u -r1.208 style.c
--- style.c	11 Mar 2003 23:14:07 -0000	1.208
+++ style.c	19 May 2003 00:54:52 -0000
@@ -724,7 +724,7 @@
 	}
 }
 
-static Bool remove_all_of_style_from_list(char *style_ref)
+static Bool remove_all_of_style_from_list(char *style_ref, XID xid)
 {
 	window_style *nptr = all_styles;
 	window_style *next;
@@ -735,7 +735,15 @@
 	{
 		next = SGET_NEXT_STYLE(*nptr);
 		/* Check if it's to be wiped */
-		if (!strcmp(SGET_NAME(*nptr), style_ref))
+		if (xid)
+		{
+			if (SGET_XID(*nptr) && SGET_XID(*nptr) == xid)
+			{
+				remove_style_from_list(nptr, True);
+				is_changed = True;
+			}
+		}
+		else if (!strcmp(SGET_NAME(*nptr), style_ref))
 		{
 			remove_style_from_list(nptr, True);
 			is_changed = True;
@@ -776,7 +784,9 @@
 		cmp = SGET_PREV_STYLE(*cur);
 		while (cmp)
 		{
-			if (strcmp(SGET_NAME(*cur), SGET_NAME(*cmp)) != 0)
+			if ((SGET_XID(*cur) && SGET_XID(*cur) != SGET_XID(*cmp))
+			    || (!SGET_XID(*cur) &&
+				strcmp(SGET_NAME(*cur), SGET_NAME(*cmp)) != 0))
 			{
 				blockor((char *)&interflags,
 					(char *)&interflags,
@@ -3887,7 +3897,7 @@
  * must be freed in ProcessDestroyStyle().
  */
 
-static void __style_command(F_CMD_ARGS, char *prefix)
+static void __style_command(F_CMD_ARGS, char *prefix, Bool is_style_by_id)
 {
 	/* temp area to build name list */
 	window_style *ps;
@@ -3919,6 +3929,19 @@
 		return;
 	}
 
+	if (is_style_by_id)
+	{
+		char *tail;
+
+		SGET_XID(*ps) = (XID)strtoul (SGET_NAME(*ps), &tail, 0);
+		if (!tail || tail == SGET_NAME(*ps) || *tail != '\0')
+		{
+			free(SGET_NAME(*ps));
+			free(ps);
+			return;
+		}
+	}
+
 	parse_and_set_window_style(action, prefix, ps);
 
 	/* capture default icons */
@@ -3938,7 +3961,10 @@
 		}
 	}
 	if (last_style_in_list &&
-	    strcmp(SGET_NAME(*ps), SGET_NAME(*last_style_in_list)) == 0)
+	    ((SGET_XID(*ps) && SGET_XID(*ps) == SGET_XID(*last_style_in_list))
+	     ||
+	     (!SGET_XID(*ps) &&
+	      strcmp(SGET_NAME(*ps), SGET_NAME(*last_style_in_list)) == 0)))
 	{
 		/* merge with previous style */
 		merge_styles(last_style_in_list, ps, True);
@@ -3955,6 +3981,60 @@
 	return;
 }
 
+void __destroy_style(F_CMD_ARGS, Bool is_style_by_id)
+{
+	char *name;
+	FvwmWindow *t;
+	XID xid = 0;
+
+	/* parse style name */
+	name = PeekToken(action, &action);
+
+	/* in case there was no argument! */
+	if (name == NULL)
+	{
+		return;
+	}
+
+	if (is_style_by_id)
+	{
+		char *tail;
+		
+		xid = (XID)strtoul (name, &tail, 0);
+		if (!tail || tail == name || *tail != '\0' || xid == 0)
+		{
+			return;
+		}
+	}
+
+	/* Do it */
+	if (remove_all_of_style_from_list(name, xid))
+	{
+		/* compact the current list of styles */
+		Scr.flags.do_need_style_list_update = 1;
+	}
+	/* mark windows for update */
+	for (t = Scr.FvwmRoot.next; t != NULL && t != &Scr.FvwmRoot;
+	     t = t->next)
+	{
+		if (IS_SCHEDULED_FOR_DESTROY(t))
+		{
+			continue;
+		}
+		if ((xid && xid == (XID)FW_W(t)) ||
+		    (!xid &&
+		     (matchWildcards(name, t->class.res_class) == TRUE ||
+		      matchWildcards(name, t->class.res_name) == TRUE ||
+		      matchWildcards(name, t->name.name) == TRUE)))
+		{
+			SET_STYLE_DELETED(t, 1);
+			Scr.flags.do_need_window_update = 1;
+		}
+	}
+
+	return;
+}
+
 /* ---------------------------- interface functions ------------------------- */
 
 /* Compare two flag structures passed as byte arrays. Only compare bits set in
@@ -4036,9 +4116,13 @@
 	/* look thru all styles in order defined. */
 	for (nptr = all_styles; nptr != NULL; nptr = SGET_NEXT_STYLE(*nptr))
 	{
-		/* If name/res_class/res_name match, merge */
-		if (matchWildcards(SGET_NAME(*nptr),fw->class.res_class) ==
-		    TRUE)
+		/* If xid/name/res_class/res_name match, merge */
+		if (SGET_XID(*nptr) && SGET_XID(*nptr) == (XID)FW_W(fw))
+		{
+			merge_styles(styles, nptr, False);
+		}
+		else if (matchWildcards(SGET_NAME(*nptr),fw->class.res_class) ==
+			 TRUE)
 		{
 			merge_styles(styles, nptr, False);
 		}
@@ -4114,8 +4198,9 @@
 	if (IS_STYLE_DELETED(t))
 	{
 		/* update all styles */
-		memset(flags, 0xff, sizeof(*flags));
+		memset(flags, 0xff, sizeof(update_win));
 		SET_STYLE_DELETED(t, 0);
+		fprintf(stderr,"FP: %i\n", flags->do_setup_focus_policy);
 		return;
 	}
 
@@ -4765,48 +4850,35 @@
 
 void CMD_Style(F_CMD_ARGS)
 {
-	__style_command(F_PASS_ARGS, NULL);
+	__style_command(F_PASS_ARGS, NULL, False);
 
 	return;
 }
 
 void CMD_FocusStyle(F_CMD_ARGS)
 {
-	__style_command(F_PASS_ARGS, "FP");
+	__style_command(F_PASS_ARGS, "FP", False);
 
 	return;
 }
 
-void CMD_DestroyStyle(F_CMD_ARGS)
+void CMD_StyleById(F_CMD_ARGS)
 {
-	char *name;
-	FvwmWindow *t;
+	__style_command(F_PASS_ARGS, NULL, True);
 
-	/* parse style name */
-	name = PeekToken(action, &action);
+	return;
+}
 
-	/* in case there was no argument! */
-	if (name == NULL)
-		return;
+void CMD_DestroyStyle(F_CMD_ARGS)
+{
+	__destroy_style(F_PASS_ARGS, False);
 
-	/* Do it */
-	if (remove_all_of_style_from_list(name))
-	{
-		/* compact the current list of styles */
-		Scr.flags.do_need_style_list_update = 1;
-	}
-	/* mark windows for update */
-	for (t = Scr.FvwmRoot.next; t != NULL && t != &Scr.FvwmRoot;
-	     t = t->next)
-	{
-		if (matchWildcards(name, t->class.res_class) == TRUE ||
-		    matchWildcards(name, t->class.res_name) == TRUE ||
-		    matchWildcards(name, t->name.name) == TRUE)
-		{
-			SET_STYLE_DELETED(t, 1);
-			Scr.flags.do_need_window_update = 1;
-		}
-	}
+	return;
+}
+
+void CMD_DestroyStyleById(F_CMD_ARGS)
+{
+	__destroy_style(F_PASS_ARGS, True);
 
 	return;
 }
Index: style.h
===================================================================
RCS file: /home/cvs/fvwm/fvwm/fvwm/style.h,v
retrieving revision 1.74
diff -u -r1.74 style.h
--- style.h	31 Dec 2002 07:45:18 -0000	1.74
+++ style.h	19 May 2003 00:54:53 -0000
@@ -364,6 +364,8 @@
 	((s).name)
 #define SSET_NAME(s,x) \
 	((s).name = (x))
+#define SGET_XID(s) \
+	((s).xid)
 #define SGET_ICON_NAME(s) \
 	((s).icon_name)
 #define SSET_ICON_NAME(s,x) \

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 19 May 2003 02:13:59 +0000

On 19 May 2003 03:01:38 +0200, Olivier Chapuis wrote:
> 
> 	Pick StyleById $[w.id] NoTitle, !Borders

Is this a final syntax we want to have? I prefer:

  Pick WindowStyle NoTitle, !Borders

Both StyleById and DestroyById (i.e. WindowStyle and DestroyWindowStyle)
don't make any sense on an unexisting window id, so they may work on the
window context just fine.

I think Tim suggested this syntax some years ago together with
SetupFunction, but I can't verify this right now.

Regards,
Mikhael.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 19 May 2003 08:52:23 +0200

> feature freeze) a vote against it. Any one?

Adding the patch to 2.5.x is out of the question (feature freeze).
Apart from that, this topic requires much more thought.  We don't
want to make an ad-hoc syntax now, find out later that it does not
work with all the other Style related enhancements and the
redesign exevrything from scratch.

> Then, the xterm has ClickToFocus (need a recapture to get SloppyFocus).

I'll look into it.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 19 May 2003 10:06:59 +0200

> > Then, the xterm has ClickToFocus (need a recapture to get SloppyFocus).

Should be fixed now.

Bye

Dominik ^_^  ^_^

---

From: Tim Phipps <[email-masked]>
Date: Mon, 19 May 2003 10:52:06 +0100

>SetupFunction, but I can't verify this right now.
I did, the spec is in WindowStyle_proposal.txt in CVS. I was waiting for 
the feature freeze to be over before starting on it.

Cheers,
Tim.

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 19 May 2003 10:39:30 +0000

> redesign exevrything from scratch.

I would like to see WindowStyle and DestroyWindowStyle in 2.6.x as
implemented in the patch, it makes many things clean and possible.

Either it is called new or old, it's a good feature. Can you argue that:

  * We all (users/developers) dreamed about window specific Style.

  * The patch in the question is not problematic (you may verify it).

  * We already discussed WindowStyle and decided (including Dominik) that
    this is the right thing to do. It even (together with StyleFunction)
    may eventually replace Style as we know it now. Having WindowStyle
    that works on window context is good regardless of whether we have
    Style or StyleFunction.

  * Style by id (works on one existing window) and Style by name (works
    on many existing and non-existing windows) should not be mixed, i.e.
    it should be 2 different commands with the first having a preference.

  * In the future all individual window states may be mixed with
    individual window styles, i.e. "Stick" is just "WindowStyle Sticky",
    but this is for the future. Currently we just need WindowStyle
    as defined by the posted patch (with the command name changed).

To see WindowStyle is not really a new suggestion, here is a thread:

  http://www.hpc.uh.edu/fvwm/archive/0112/msg00226.html

(all "WindowId $0" tips should be read as "ThisWindow" in the thread.)
Again, the whole implementation of this is for the future, adding
WindowStyle now is only a small and safe step in this direction.
Even if in the future some internals may be changed the syntax is not.

Regards,
Mikhael.

---

From: Olivier Chapuis <[email-masked]>
Date: Mon, 19 May 2003 12:52:47 +0200

> Adding the patch to 2.5.x is out of the question (feature freeze).

During 2.3.x we added new features during feature freeze.  Of course
adding a new feature should lead to discussion and voting. But I do
not think that we _must_ not add some.  During development period we
may, for various reasons, postpone/forget/miss certain stuff. Then,
during feature freeze we can "fix" these stuff. 

> redesign exevrything from scratch.

Oh yes. For me, these commands are just _workaround_ commands: This
feature is important and it is easy to get it so why we should live
without it?
Because, we have an ambitious project "the WindowStyle command" which
leads to "Conditional Style"?
Well, with the current FVWM development logic we will have to wait 3
years to get something that can do what StyleById can do now (and I am
optimist ... I do not think that we should start a discussion on FVWM
future now). 

Regards, Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 19 May 2003 13:16:37 +0200

> Either it is called new or old, it's a good feature. Can you argue that:

2.5.x is in feature freeze.  If you feel the need to add new and
potentially disrupting features now, please split off a new
project and do it in a separate CVS repository.  Full stop.

>   * The patch in the question is not problematic (you may verify it).

Of course it is problematic.  Style handling itself is very
delicate and one of the richest sources of bugs.  Just read the
archives to get a feeling for what I mean.

>     that works on window context is good regardless of whether we have

Please speak only for yourself.  I never agreed to a particular
solution and I won't participate in a design discussion at this
point in time.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 19 May 2003 13:22:58 +0200

> during feature freeze we can "fix" these stuff. 

I am trying to stabilise fvwm and patches of this dimension have
the potential to throw us back for months.

> leads to "Conditional Style"?

See my reply to Mikhael's post.  If you prefer a neverending beta
status, we can not work on the same project.

> years to get something that can do what StyleById can do now

Everybody is welcome to help solving the problems that stand
between 2.5.6 and 2.6.0.

> (and I am > optimist ... I do not think that we should start a 
> discussion on FVWM future now). 

Bye

Dominik ^_^  ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Mon, 19 May 2003 13:46:14 +0200

On Mon, May 19, 2003 at 01:22:58PM +0200, Dominik Vogt wrote:
> I am trying to stabilise fvwm

We (all) are trying to stabilise fvwm ...

> and patches of this dimension have

I do not think so. It may cause problems but does not lead
to such a delay.

> status, we can not work on the same project.

Why do you use such argument?

> Everybody is welcome to help solving the problems that stand

And of course I do nothing for that :o)
 
Regards, Olivier