Re: PATCH: StartMaximized
2009/2/8 Dominik Vogt dominik.v...@gmx.de: On Sat, Feb 07, 2009 at 08:27:54PM +, Thomas Adam wrote: I recommend you consider comitting this to CVS, and perhaps release a new unstable version? I think there's enough material in there now to warrant that. Applied. Try to remind me of the new release next week. Dominik -- consider this officially reminded. :) Apologies for not having a patch for removing libs/ from include paths -- although I have several other patches in the mix, I don't want to submit any of them until we sort of this PrintInfo bindings stuff first -- but again, do not consider this any pressure, just a gentle reminder. :) -- Thomas Adam
Re: PATCH: StartMaximized
On 07Feb2009 20:51, Dominik Vogt dominik.v...@gmx.de wrote: | [...] I have attached a much smaller version of the | patch that removes all code that replaces other styles and fixes a | couple of small problems: | | * Don't look up the style in events.c again but pass the string | back from AddWindow(). As a side effect, the command is only | executed when the window is mapped initially, not when it's | mapped because of deiconification. Therefore I renamed the | style to InitialMapCommand (which may or may not be a good | idea). I'm +1 on the changed name - I like the distinction, unless someone likes with: MapCommand [Initial|Every|condition] command... I.e. have an optional leading condition to MapCommand. Just my 2c, -- Cameron Simpson c...@zip.com.au DoD#743
Re: PATCH: StartMaximized
On Sat, Feb 07, 2009 at 08:27:54PM +, Thomas Adam wrote: 2009/2/7 Dominik Vogt dominik.v...@gmx.de: On Fri, Feb 06, 2009 at 09:35:30AM +, Thomas Adam wrote: 2009/2/6 Dominik Vogt dominik.v...@gmx.de: On Thu, Feb 05, 2009 at 10:55:16PM +, Thomas Adam wrote: 2009/1/26 Thomas Adam thomas.ada...@gmail.com: I was planning to look into the patch on saturday evening (GMT) or maybe earlier. Ah, OK. Please don't think I'm forcing your hand on this, I just never know how much time to give between pauses before I give a gentle reminder that I haven't completely abandoned an idea. :) Neither have I. I have attached a much smaller version of the patch that removes all code that replaces other styles and fixes a couple of small problems: * Don't look up the style in events.c again but pass the string back from AddWindow(). As a side effect, the command is only executed when the window is mapped initially, not when it's mapped because of deiconification. Therefore I renamed the style to InitialMapCommand (which may or may not be a good idea). Ok, that looks fine to me. Note initialMapCommand is also fine with me, as it really does just that. Anything else would be shed-painting if you ask me, and I have to deal with that enough at work. :) * Call execute_function_override_window() with the proper execution context. Please see the attached patch which also adds the relevant documentation to go with this new style. I've not bothered to update AUTHORS or anything like that, you've thankfully saved me the trouble. I recommend you consider comitting this to CVS, and perhaps release a new unstable version? I think there's enough material in there now to warrant that. Applied. Try to remind me of the new release next week. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: PATCH: StartMaximized
On Fri, Feb 06, 2009 at 09:35:30AM +, Thomas Adam wrote:
2009/2/6 Dominik Vogt dominik.v...@gmx.de:
On Thu, Feb 05, 2009 at 10:55:16PM +, Thomas Adam wrote:
2009/1/26 Thomas Adam thomas.ada...@gmail.com:
I was planning to look into the patch on saturday evening (GMT) or
maybe earlier.
Ah, OK. Please don't think I'm forcing your hand on this, I just
never know how much time to give between pauses before I give a gentle
reminder that I haven't completely abandoned an idea. :)
Neither have I. I have attached a much smaller version of the
patch that removes all code that replaces other styles and fixes a
couple of small problems:
* Don't look up the style in events.c again but pass the string
back from AddWindow(). As a side effect, the command is only
executed when the window is mapped initially, not when it's
mapped because of deiconification. Therefore I renamed the
style to InitialMapCommand (which may or may not be a good
idea).
* Call execute_function_override_window() with the proper
execution context.
Is it worth, whilst I am looking at the code, to deprecate
StartsOnDesk, seeing as StartsOnPage has this functionality anyway,
Has it? Can you give an example?
Sure (From within FvwmConsole):
FvwmPager 0 3
Style Foo StartsOnPage 2
Exec exec xterm -T Foo
... will place the new window Foo on Desk 2. Note that this was one
of the reasons I came up with the new StartsOnLocation, which
effectively deprecated StartsOnDesk/StartsOnScreen, because
StartsOnDesk is already present in StartsOnPage, and because adding in
an optional screen [num] parameter to StartsOnPage made sense. Of
course, StartsOnPage with just one parameter feels wrong because it's
not a page, it's now a Desk -- hence the name change to
StartsOnLocation.
Your're right. StartsOnDesk could have been removed when
StartsOnPage was introduced.
But this would break too many configs, I feel.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
? InitialMapComman.patch
Index: ChangeLog
===
RCS file: /home/cvs/fvwm/fvwm/ChangeLog,v
retrieving revision 1.3061
diff -u -r1.3061 ChangeLog
--- ChangeLog 30 Dec 2008 13:32:40 - 1.3061
+++ ChangeLog 7 Feb 2009 19:44:36 -
@@ -1,3 +1,11 @@
+2009-02-07 Dominik Vogt dominik(dot)vogt(at)gmx(dot)de
+
+ * fvwm/events.c (HandleMapRequestKeepRaised):
+ * fvwm/add_window.c (AddWindow):
+ * fvwm/style.h:
+ * fvwm/style.c (style_parse_one_style_option):
+ add new style InitialMapCommand
+
2008-12-29 Alexandre Julliard julli...@winehq.org
* fvwm/ewmh_events.c (ewmh_WMStateMaxHoriz):
Index: NEWS
===
RCS file: /home/cvs/fvwm/fvwm/NEWS,v
retrieving revision 1.767
diff -u -r1.767 NEWS
--- NEWS 30 Dec 2008 13:32:40 - 1.767
+++ NEWS 7 Feb 2009 19:44:40 -
@@ -18,6 +18,9 @@
... is now honoured. Useful with IndexedWindowName as a style
option.
+ - New style InitialMapCommand allows to execute any command
+ when a window is mapped first.
+
* Bug fixes:
- Fixed compilation without XRender support.
Index: fvwm/add_window.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/add_window.c,v
retrieving revision 1.398
diff -u -r1.398 add_window.c
--- fvwm/add_window.c 6 Aug 2008 17:55:28 - 1.398
+++ fvwm/add_window.c 7 Feb 2009 19:44:45 -
@@ -2125,8 +2125,8 @@
*
*/
FvwmWindow *AddWindow(
- const exec_context_t *exc, FvwmWindow *ReuseWin,
- initial_window_options_t * win_opts)
+ const char **ret_initial_map_command, const exec_context_t *exc,
+ FvwmWindow *ReuseWin, initial_window_options_t * win_opts)
{
/* new fvwm window structure */
register FvwmWindow *fw;
@@ -2242,6 +2242,11 @@
fw-class.res_class);
}
+ /** InitialMapCommand **/
+ *ret_initial_map_command =
+ (style.flags.has_initial_map_command_string) ?
+ SGET_INITIAL_MAP_COMMAND_STRING(style) : NULL;
+
/** state setup **/
setup_icon_boxes(fw, style);
SET_ICONIFIED(fw, 0);
Index: fvwm/add_window.h
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/add_window.h,v
retrieving revision 1.38
diff -u -r1.38 add_window.h
--- fvwm/add_window.h 17 Nov 2007 11:47:56 - 1.38
+++ fvwm/add_window.h 7 Feb 2009 19:44:45 -
@@ -58,8 +58,8 @@
void FetchWmProtocols(
FvwmWindow *);
FvwmWindow *AddWindow(
- const exec_context_t *exc, FvwmWindow *ReuseWin,
- initial_window_options_t * win_opts);
+ const char **ret_initial_map_command, const exec_context_t *exc,
+ FvwmWindow *ReuseWin, initial_window_options_t * win_opts);
void GetWindowSizeHints(
FvwmWindow *);
void free_window_names(
Index: fvwm/events.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/events.c,v
retrieving revision 1.561
diff -u -r1.561 events.c
---
Re: PATCH: StartMaximized
2009/2/7 Dominik Vogt dominik.v...@gmx.de:
On Fri, Feb 06, 2009 at 09:35:30AM +, Thomas Adam wrote:
2009/2/6 Dominik Vogt dominik.v...@gmx.de:
On Thu, Feb 05, 2009 at 10:55:16PM +, Thomas Adam wrote:
2009/1/26 Thomas Adam thomas.ada...@gmail.com:
I was planning to look into the patch on saturday evening (GMT) or
maybe earlier.
Ah, OK. Please don't think I'm forcing your hand on this, I just
never know how much time to give between pauses before I give a gentle
reminder that I haven't completely abandoned an idea. :)
Neither have I. I have attached a much smaller version of the
patch that removes all code that replaces other styles and fixes a
couple of small problems:
* Don't look up the style in events.c again but pass the string
back from AddWindow(). As a side effect, the command is only
executed when the window is mapped initially, not when it's
mapped because of deiconification. Therefore I renamed the
style to InitialMapCommand (which may or may not be a good
idea).
Ok, that looks fine to me. Note initialMapCommand is also fine with
me, as it really does just that. Anything else would be shed-painting
if you ask me, and I have to deal with that enough at work. :)
* Call execute_function_override_window() with the proper
execution context.
Please see the attached patch which also adds the relevant
documentation to go with this new style. I've not bothered to update
AUTHORS or anything like that, you've thankfully saved me the trouble.
I recommend you consider comitting this to CVS, and perhaps release a
new unstable version? I think there's enough material in there now to
warrant that.
-- Thomas Adam
Index: ChangeLog
===
RCS file: /home/cvs/fvwm/fvwm/ChangeLog,v
retrieving revision 1.3061
diff -u -r1.3061 ChangeLog
--- ChangeLog 30 Dec 2008 13:32:40 - 1.3061
+++ ChangeLog 7 Feb 2009 20:23:22 -
@@ -1,3 +1,11 @@
+2009-02-07 Dominik Vogt dominik(dot)vogt(at)gmx(dot)de
+
+ * fvwm/events.c (HandleMapRequestKeepRaised):
+ * fvwm/add_window.c (AddWindow):
+ * fvwm/style.h:
+ * fvwm/style.c (style_parse_one_style_option):
+ add new style InitialMapCommand
+
2008-12-29 Alexandre Julliard julli...@winehq.org
* fvwm/ewmh_events.c (ewmh_WMStateMaxHoriz):
Index: NEWS
===
RCS file: /home/cvs/fvwm/fvwm/NEWS,v
retrieving revision 1.767
diff -u -r1.767 NEWS
--- NEWS 30 Dec 2008 13:32:40 - 1.767
+++ NEWS 7 Feb 2009 20:23:23 -
@@ -18,6 +18,9 @@
... is now honoured. Useful with IndexedWindowName as a style
option.
+ - New style InitialMapCommand allows to execute any command
+ when a window is mapped first.
+
* Bug fixes:
- Fixed compilation without XRender support.
Index: doc/commands/Style.xml
===
RCS file: /home/cvs/fvwm/fvwm/doc/commands/Style.xml,v
retrieving revision 1.9
diff -u -r1.9 Style.xml
--- doc/commands/Style.xml 19 Oct 2008 12:04:13 - 1.9
+++ doc/commands/Style.xml 7 Feb 2009 20:23:25 -
@@ -204,6 +204,7 @@
emphasis remap='I'EdgeMoveDelay/emphasis,
emphasis remap='I'EdgeResizeDelay/emphasis.
emphasis remap='I'EdgeMoveResistance/emphasis,
+emphasis remap='I'InitialMapCommand/emphasis
/para
@@ -1360,8 +1361,18 @@
opt=EdgeMoveResistance/ can be used without any
parameters./para
+paraThe option fvwmopt cmd=Style opt=InitialMapCommand/ allows
+for any valid fvwm command or function to run when the window is
+initially mapped by fvwm. Example:/para
+
+programlisting
+fvwmref cmd=Style/ MyWindow StartsOnPage 0 0, InitialMapCommand Iconify
+/programlisting
/section
+paraThis would hence place the window called emphasisMyWindow/emphasis
+on page 0 0 for the current desk, and immediately run the fvwmref cmd=Iconify/
+command on that window./para
section id=window_manager_placement
Index: fvwm/add_window.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/add_window.c,v
retrieving revision 1.398
diff -u -r1.398 add_window.c
--- fvwm/add_window.c 6 Aug 2008 17:55:28 - 1.398
+++ fvwm/add_window.c 7 Feb 2009 20:23:27 -
@@ -2125,8 +2125,8 @@
*
*/
FvwmWindow *AddWindow(
- const exec_context_t *exc, FvwmWindow *ReuseWin,
- initial_window_options_t * win_opts)
+ const char **ret_initial_map_command, const exec_context_t *exc,
+ FvwmWindow *ReuseWin, initial_window_options_t * win_opts)
{
/* new fvwm window structure */
register FvwmWindow *fw;
@@ -2242,6 +2242,11 @@
fw-class.res_class);
}
+ /** InitialMapCommand **/
+ *ret_initial_map_command =
+ (style.flags.has_initial_map_command_string) ?
+ SGET_INITIAL_MAP_COMMAND_STRING(style) : NULL;
+
/** state setup **/
setup_icon_boxes(fw, style);
SET_ICONIFIED(fw, 0);
Index: fvwm/add_window.h
Re: PATCH: StartMaximized
On Thu, Feb 05, 2009 at 10:55:16PM +, Thomas Adam wrote:
2009/1/26 Thomas Adam thomas.ada...@gmail.com:
I like this idea, actually, but the changes involved would be vast --
however certainly very interesting to work on for the future. Would
you and others be willing to flesh this out further? I really like
the idea, and having a design for this, if only for the future would
be cool.
I appreciate everyone's busy doing other things, so I shall say that I
plan to reinstate the StartsOn{Desk,Screen,Page} style commands for
now, and just have MapCommand accept anything (i.e., it won't consider
StartsOnLocation as per my original patch as a special case -- the
change is just too fundamental and would break almost all configs out
there). I'll do this over this coming weekend and will resubmit this
patch with the appropriate documentation.
If anyone has any objections to this, do let me know. I don't
consider it a waste of my time to do the work, but I'd rather know
sooner rather than later. :)
I was planning to look into the patch on saturday evening (GMT) or
maybe earlier.
Is it worth, whilst I am looking at the code, to deprecate
StartsOnDesk, seeing as StartsOnPage has this functionality anyway,
Has it? Can you give an example?
or
is this still too a risque thing to do?
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: PATCH: StartMaximized
2009/2/6 Dominik Vogt dominik.v...@gmx.de:
On Thu, Feb 05, 2009 at 10:55:16PM +, Thomas Adam wrote:
2009/1/26 Thomas Adam thomas.ada...@gmail.com:
I like this idea, actually, but the changes involved would be vast --
however certainly very interesting to work on for the future. Would
you and others be willing to flesh this out further? I really like
the idea, and having a design for this, if only for the future would
be cool.
I appreciate everyone's busy doing other things, so I shall say that I
plan to reinstate the StartsOn{Desk,Screen,Page} style commands for
now, and just have MapCommand accept anything (i.e., it won't consider
StartsOnLocation as per my original patch as a special case -- the
change is just too fundamental and would break almost all configs out
there). I'll do this over this coming weekend and will resubmit this
patch with the appropriate documentation.
If anyone has any objections to this, do let me know. I don't
consider it a waste of my time to do the work, but I'd rather know
sooner rather than later. :)
I was planning to look into the patch on saturday evening (GMT) or
maybe earlier.
Ah, OK. Please don't think I'm forcing your hand on this, I just
never know how much time to give between pauses before I give a gentle
reminder that I haven't completely abandoned an idea. :)
Is it worth, whilst I am looking at the code, to deprecate
StartsOnDesk, seeing as StartsOnPage has this functionality anyway,
Has it? Can you give an example?
Sure (From within FvwmConsole):
FvwmPager 0 3
Style Foo StartsOnPage 2
Exec exec xterm -T Foo
... will place the new window Foo on Desk 2. Note that this was one
of the reasons I came up with the new StartsOnLocation, which
effectively deprecated StartsOnDesk/StartsOnScreen, because
StartsOnDesk is already present in StartsOnPage, and because adding in
an optional screen [num] parameter to StartsOnPage made sense. Of
course, StartsOnPage with just one parameter feels wrong because it's
not a page, it's now a Desk -- hence the name change to
StartsOnLocation. But this would break too many configs, I feel.
Kindly,
-- Thomas Adam
Re: PATCH: StartMaximized
2009/1/26 Thomas Adam thomas.ada...@gmail.com:
I like this idea, actually, but the changes involved would be vast --
however certainly very interesting to work on for the future. Would
you and others be willing to flesh this out further? I really like
the idea, and having a design for this, if only for the future would
be cool.
I appreciate everyone's busy doing other things, so I shall say that I
plan to reinstate the StartsOn{Desk,Screen,Page} style commands for
now, and just have MapCommand accept anything (i.e., it won't consider
StartsOnLocation as per my original patch as a special case -- the
change is just too fundamental and would break almost all configs out
there). I'll do this over this coming weekend and will resubmit this
patch with the appropriate documentation.
If anyone has any objections to this, do let me know. I don't
consider it a waste of my time to do the work, but I'd rather know
sooner rather than later. :)
Is it worth, whilst I am looking at the code, to deprecate
StartsOnDesk, seeing as StartsOnPage has this functionality anyway, or
is this still too a risque thing to do?
Kindly,
-- Thomas Adam
Re: PATCH: StartMaximized
On Sun, Jan 25, 2009 at 11:28:51PM +, Thomas Adam wrote:
2009/1/22 Thomas Adam thomas.ada...@gmail.com:
2009/1/22 Dominik Vogt dominik.v...@gmx.de:
On Thu, Jan 22, 2009 at 09:01:44AM +, Thomas Adam wrote:
2009/1/22 Dominik Vogt dominik.v...@gmx.de:
Style Foo MapFooFunc
AddToFunc MapFooFunc
+ I MoveToPage 1 1
+ I Iconify true
This way, it would even be possible to get these stupid Open
Office windows under control that shade themselves on startup.
I am not following you here. What's the relationship between
MapFooFunc and InitWindowCommand?
Er, I wanted to type
Style Foo InitWindowCommand MapFooFunc
Ah ha. And suddenly all becomes clear.
I shall come up with something soon enough for review. Should be fun.
And so I have. I've made MapCommand accept anything (i.e., a valid
FVWM builtin, or a defined function)
Thanks, I'll try out the patch soon.
and in so doing have done the following:
* Deprecate StartsRaised in favour of: Style foo MapCommand Raise
* Deprecate StartsLowered in favout of: Style foo MapCommand Lower
* Deprecate StartIconic in favour of: Style foo MapCommand Iconify
* Deprecate StartNormal in favour of: Style foo MapCommand Iconify off
* Deprecate StartShaded in favour of: Style foo MapCommand WindowShade dir
I've also deprecated StartsOnPage/Desk/Screen in favour of:
I'm unsure whether this is a good thing to do. There should be a
consistent way of having many commands as styles, including all
arguments, but the MapCommand is not a general solution. For
example, with MapCommand windows will flash on the current screen
first and be moved to the page specified with the StartsOnPage
substitute only after that. So deprecating the styles would
actually impair the functionality.
Style foo MapWindow StartsOnLocation [screen x] a b c
Where StartsOnLocation works exactly like StartsOnPage, but now
accepts an optional screen x parameter for specifying a starting
screen.
I am considering the attached patch to be nothing more than a
proof-of-concept, so testing/feedback is welcome, I daresay it's a
little rough around the edges, and I expect that.
Perhaps the only damaging change is in deprecating the
aforementioned options, I really have done just that -- i.e., there
really is no further support for them other than a standard
deprecation message should FVWM find one of these style commands. I
realise this breaks any chance of backwards compatability, but it
allows for removing code no longer needed if this MapCommand is
accepted.
Because this is a proof-of-concept patch, I've deliberately not
written any documentation yet until I get some feedback.
Kindly,
-- Thomas Adam
Index: fvwm/add_window.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/add_window.c,v
retrieving revision 1.398
diff -u -r1.398 add_window.c
--- fvwm/add_window.c 6 Aug 2008 17:55:28 - 1.398
+++ fvwm/add_window.c 25 Jan 2009 22:39:24 -
@@ -2436,7 +2436,12 @@
BroadcastWindowIconNames(fw, True, False);
/** place the window in the stack ring **/
- if (!position_new_window_in_stack_ring(fw, SDO_START_LOWERED(sflags)))
+ /* TA: 20090124: We don't explicitly lower the window -- leave it in
+ * the default layer. This can be overrided by:
+ *
+ * MapCommand Lower
+ */
+ if (!position_new_window_in_stack_ring(fw, 0))
{
XWindowChanges xwc;
xwc.sibling = FW_W_FRAME(get_next_window_in_stack_ring(fw));
@@ -2535,7 +2540,7 @@
GNOME_SetWinArea(fw);
/** windowshade **/
- if (state_args.do_shade || SDO_START_SHADED(sflags))
+ if (state_args.do_shade)
{
rectangle big_g;
rectangle new_g;
@@ -2545,13 +2550,6 @@
{
state_args.shade_dir = GET_TITLE_DIR(fw);
}
- /* If we've set a style for StartShaded, ensure we override
- * the state for it here. -- TA.
- */
- if (SDO_START_SHADED(sflags) !state_args.do_shade)
- {
- state_args.shade_dir = SGET_STARTS_SHADED_DIR(style);
- }
big_g = (IS_MAXIMIZED(fw)) ? fw-g.max : fw-g.frame;
new_g = big_g;
get_shaded_geometry_with_dir(
Index: fvwm/events.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/events.c,v
retrieving revision 1.561
diff -u -r1.561 events.c
--- fvwm/events.c 8 Aug 2008 11:44:01 - 1.561
+++ fvwm/events.c 25 Jan 2009 22:39:26 -
@@ -2975,6 +2975,12 @@
else
{
int state;
+
+ /* TA: 20090125: Make sure we're able to access the window
+ * flags post-mapping.
+ */
+
Re: PATCH: StartMaximized
2009/1/26 Dominik Vogt dominik.v...@gmx.de: On Sun, Jan 25, 2009 at 11:28:51PM +, Thomas Adam wrote: 2009/1/22 Thomas Adam thomas.ada...@gmail.com: I've also deprecated StartsOnPage/Desk/Screen in favour of: I'm unsure whether this is a good thing to do. There should be a consistent way of having many commands as styles, including all arguments, but the MapCommand is not a general solution. For Hmm -- but then you have to go down the route of: Style foo MapCommand A, MapCommand B someoptions, \ MapCommand C optionA optionB Which is fine I suppose, but might get confusing since the ordering is then enforced on the user. Is this what you were referring to when you said many commands? example, with MapCommand windows will flash on the current screen first and be moved to the page specified with the StartsOnPage substitute only after that. So deprecating the styles would actually impair the functionality. Yes, the flashing is a possibility, although having tested this quite a bit over the weekend, I can't say I have noticed it at all. What would you suggest then? If we keep StartsOnScreen and friends as separare entities, that doesn't provide a generic solution either. -- Thomas Adam
Re: PATCH: StartMaximized
On Mon, Jan 26, 2009 at 10:06:07AM +, Thomas Adam wrote: 2009/1/26 Dominik Vogt dominik.v...@gmx.de: On Sun, Jan 25, 2009 at 11:28:51PM +, Thomas Adam wrote: 2009/1/22 Thomas Adam thomas.ada...@gmail.com: I've also deprecated StartsOnPage/Desk/Screen in favour of: I'm unsure whether this is a good thing to do. There should be a consistent way of having many commands as styles, including all arguments, but the MapCommand is not a general solution. For Hmm -- but then you have to go down the route of: Style foo MapCommand A, MapCommand B someoptions, \ MapCommand C optionA optionB Which is fine I suppose, but might get confusing since the ordering is then enforced on the user. Is this what you were referring to when you said many commands? What I actually meant is that we have a lot of commands that should be present as styles at window startup only, for example Iconify, Layer, Move, Maximize, Shade, Raise, Lower, etc. The MapCommand style is - in my eyes - only a (temporary) workaround for allowing Command args as well as Style * Stylename corresponding with commandname args e.g. Maximize 50 100 Style * Maximized 50 100 Fvwm has no clear concept behind styles and commands. I rather think of it as window state that affects how windows look and behave. We have * initial window state (upon mapping the window) * current window state * default or custom window state Default state means that a specific facet of the window state has not been changed and that a change of style will affect this window whereas custom state means that whis feacet was changed for this window only and that the window is now unaffected by style changes of this facet. Example with some hypothetic commands: InitialWindowState * Maximize off, Shade on Next (foo) SetWindowState Shade off Note that Next (foo) is just a way of specifying a set of windows (one window in this case), just like InitialWindowState * selects all windows. This concept simply boils down to a stack of state definitions of which the most specific one wins (separately for each facet of window behaviour). States could be stored in some kind of database that allows efficient search algorithms for a specific facet of a given window. Since this would entail a complete rewrite of huge amounts of code it will probably be never implemented. (And of course it would completely change fvwm's syntax.) example, with MapCommand windows will flash on the current screen first and be moved to the page specified with the StartsOnPage substitute only after that. So deprecating the styles would actually impair the functionality. Yes, the flashing is a possibility, although having tested this quite a bit over the weekend, I can't say I have noticed it at all. What would you suggest then? If we keep StartsOnScreen and friends as separare entities, that doesn't provide a generic solution either. I suggest we just add the new style for now and leave all other styles as they are now. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: PATCH: StartMaximized
2009/1/26 Dominik Vogt dominik.v...@gmx.de: On Mon, Jan 26, 2009 at 10:06:07AM +, Thomas Adam wrote: 2009/1/26 Dominik Vogt dominik.v...@gmx.de: On Sun, Jan 25, 2009 at 11:28:51PM +, Thomas Adam wrote: 2009/1/22 Thomas Adam thomas.ada...@gmail.com: I've also deprecated StartsOnPage/Desk/Screen in favour of: I'm unsure whether this is a good thing to do. There should be a consistent way of having many commands as styles, including all arguments, but the MapCommand is not a general solution. For Hmm -- but then you have to go down the route of: Style foo MapCommand A, MapCommand B someoptions, \ MapCommand C optionA optionB Which is fine I suppose, but might get confusing since the ordering is then enforced on the user. Is this what you were referring to when you said many commands? What I actually meant is that we have a lot of commands that should be present as styles at window startup only, for example Iconify, Layer, Move, Maximize, Shade, Raise, Lower, etc. The MapCommand style is - in my eyes - only a (temporary) workaround for allowing Command args as well as Style * Stylename corresponding with commandname args Indeed -- something which meets this halfway, if only temporary might still be useful. e.g. Maximize 50 100 Style * Maximized 50 100 Fvwm has no clear concept behind styles and commands. I rather think of it as window state that affects how windows look and behave. We have * initial window state (upon mapping the window) * current window state * default or custom window state Default state means that a specific facet of the window state has not been changed and that a change of style will affect this window whereas custom state means that whis feacet was changed for this window only and that the window is now unaffected by style changes of this facet. Example with some hypothetic commands: I like this idea, actually, but the changes involved would be vast -- however certainly very interesting to work on for the future. Would you and others be willing to flesh this out further? I really like the idea, and having a design for this, if only for the future would be cool. InitialWindowState * Maximize off, Shade on Next (foo) SetWindowState Shade off Note that Next (foo) is just a way of specifying a set of windows (one window in this case), just like InitialWindowState * selects all windows. This concept simply boils down to a stack of state definitions of which the most specific one wins (separately for each facet of window behaviour). States could be stored in some kind of database that allows efficient search algorithms for a specific facet of a given window. Agreed -- the principle seems sound. Since this would entail a complete rewrite of huge amounts of code it will probably be never implemented. (And of course it would completely change fvwm's syntax.) If this idea is taken seriously long-term, I would really like to help implement something like this, FWIW. :) Squashed into this is the idea of having styles match specific subsets of a window's name or class as in: Style (class=MyWindow,Name=Bob) SomeCommand Although that in itself is a fair chunk of rewrite. (Something like this does already exist, although I don't know how far off the ground it was ever taken -- it's in CVS on a branch anyway.) I suggest we just add the new style for now and leave all other styles as they are now. You mean clean up my abomination^H^H^Hpatch (making the suggestions about StaysPut, etc)? If I went and did that and wrote some documentation for it, I suppose it might help. I am still apprehensive about what to do with the styles I've proposed as deprecated. I know I took a bulldozer attempt at that, but could I get a concrete answer on this? Putting a warning about their deprecation is fine -- but do we still have them as valid styles anyway? (Which might cause some interesting conditions with using MapCommand) I know 2.5.X is experimental, etc., etc., but this is potentially a big change and would break almost everyone's config. Thanks for your feedback and ideas, they're really rather interesting. :) Kindly, -- Thomas Adam
Re: PATCH: StartMaximized
2009/1/22 Thomas Adam thomas.ada...@gmail.com:
2009/1/22 Dominik Vogt dominik.v...@gmx.de:
On Thu, Jan 22, 2009 at 09:01:44AM +, Thomas Adam wrote:
2009/1/22 Dominik Vogt dominik.v...@gmx.de:
Style Foo MapFooFunc
AddToFunc MapFooFunc
+ I MoveToPage 1 1
+ I Iconify true
This way, it would even be possible to get these stupid Open
Office windows under control that shade themselves on startup.
I am not following you here. What's the relationship between
MapFooFunc and InitWindowCommand?
Er, I wanted to type
Style Foo InitWindowCommand MapFooFunc
Ah ha. And suddenly all becomes clear.
I shall come up with something soon enough for review. Should be fun.
And so I have. I've made MapCommand accept anything (i.e., a valid
FVWM builtin, or a defined function) and in so doing have done the
following:
* Deprecate StartsRaised in favour of: Style foo MapCommand Raise
* Deprecate StartsLowered in favout of: Style foo MapCommand Lower
* Deprecate StartIconic in favour of: Style foo MapCommand Iconify
* Deprecate StartNormal in favour of: Style foo MapCommand Iconify off
* Deprecate StartShaded in favour of: Style foo MapCommand WindowShade dir
I've also deprecated StartsOnPage/Desk/Screen in favour of:
Style foo MapWindow StartsOnLocation [screen x] a b c
Where StartsOnLocation works exactly like StartsOnPage, but now
accepts an optional screen x parameter for specifying a starting
screen.
I am considering the attached patch to be nothing more than a
proof-of-concept, so testing/feedback is welcome, I daresay it's a
little rough around the edges, and I expect that.
Perhaps the only damaging change is in deprecating the
aforementioned options, I really have done just that -- i.e., there
really is no further support for them other than a standard
deprecation message should FVWM find one of these style commands. I
realise this breaks any chance of backwards compatability, but it
allows for removing code no longer needed if this MapCommand is
accepted.
Because this is a proof-of-concept patch, I've deliberately not
written any documentation yet until I get some feedback.
Kindly,
-- Thomas Adam
Index: fvwm/add_window.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/add_window.c,v
retrieving revision 1.398
diff -u -r1.398 add_window.c
--- fvwm/add_window.c 6 Aug 2008 17:55:28 - 1.398
+++ fvwm/add_window.c 25 Jan 2009 22:39:24 -
@@ -2436,7 +2436,12 @@
BroadcastWindowIconNames(fw, True, False);
/** place the window in the stack ring **/
- if (!position_new_window_in_stack_ring(fw, SDO_START_LOWERED(sflags)))
+ /* TA: 20090124: We don't explicitly lower the window -- leave it in
+ * the default layer. This can be overrided by:
+ *
+ * MapCommand Lower
+ */
+ if (!position_new_window_in_stack_ring(fw, 0))
{
XWindowChanges xwc;
xwc.sibling = FW_W_FRAME(get_next_window_in_stack_ring(fw));
@@ -2535,7 +2540,7 @@
GNOME_SetWinArea(fw);
/** windowshade **/
- if (state_args.do_shade || SDO_START_SHADED(sflags))
+ if (state_args.do_shade)
{
rectangle big_g;
rectangle new_g;
@@ -2545,13 +2550,6 @@
{
state_args.shade_dir = GET_TITLE_DIR(fw);
}
- /* If we've set a style for StartShaded, ensure we override
- * the state for it here. -- TA.
- */
- if (SDO_START_SHADED(sflags) !state_args.do_shade)
- {
- state_args.shade_dir = SGET_STARTS_SHADED_DIR(style);
- }
big_g = (IS_MAXIMIZED(fw)) ? fw-g.max : fw-g.frame;
new_g = big_g;
get_shaded_geometry_with_dir(
Index: fvwm/events.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/events.c,v
retrieving revision 1.561
diff -u -r1.561 events.c
--- fvwm/events.c 8 Aug 2008 11:44:01 - 1.561
+++ fvwm/events.c 25 Jan 2009 22:39:26 -
@@ -2975,6 +2975,12 @@
else
{
int state;
+
+ /* TA: 20090125: Make sure we're able to access the window
+ * flags post-mapping.
+ */
+ window_style style;
+ lookup_style(fw, style);
if (fw-wmhints (fw-wmhints-flags StateHint))
{
@@ -3055,6 +3061,16 @@
(unsigned long)fw);
#endif
}
+ /* TA: 20090125: We *have* to handle MapCommand
+ * here and not in AddWindow() to allow for correct
+ * timings when the window is truly mapped. (c.f.
+ * things like Iconify.
+ */
+ if( style.flags.has_map_command_string)
+ {
+execute_function_override_window(NULL, NULL,
+ SGET_MAP_COMMAND_STRING(style), 0, fw);
+ }
MyXUngrabServer(dpy);
break;
Index: fvwm/fvwm.h
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/fvwm.h,v
retrieving revision 1.259
diff -u -r1.259 fvwm.h
--- fvwm/fvwm.h 28 Nov 2008 23:29:27 - 1.259
+++ fvwm/fvwm.h 25 Jan 2009 22:39:27 -
@@ -594,6 +594,7 @@
unsigned has_placement_penalty : 1;
unsigned has_placement_percentage_penalty : 1;
unsigned has_placement_position_string : 1;
Re: PATCH: StartMaximized
On Mon, Jan 19, 2009 at 06:47:28AM +, Thomas Adam wrote: I've been toying around with this patch for a while now, which seems to work. Given that we have PositionPlacement which allows for placingwindows at a specific location, StartMaximized will start a window maximized, allowing for the usual arguments per the Maximize command[1]. For instance: Style somewindow PositionPlacement 0 50, \ StartMaximized growonlayers $[w.layer] -1 grow grow Or more simply: Style somewindow StartMaximized Does the new style take the same arguments as the maximize command, or does it have a different syntax? Comments/suggestions welcome. I ponder if we shouldn't have a much more generic mechanism here. At the moment we have: StartsOnDesk/Page/Screen StartsLowered/Raised StartsShaded StartIconic/Normal All of these could be replaced by a hypothetic style InitWindowCommand (stupid name, suggestions welcome): Style Foo MapFooFunc AddToFunc MapFooFunc + I MoveToPage 1 1 + I Iconify true This way, it would even be possible to get these stupid Open Office windows under control that shade themselves on startup. Of course the parsing would be difficult if the command contains commas. -- Thomas Adam [1] I found it surprising that the Maximize command has no error checking of its inputs, hence: Maximize 0 50 jlksdjsdljlksdlk silently works, regardless. I might fix this at some point. Index: AUTHORS === RCS file: /home/cvs/fvwm/fvwm/AUTHORS,v retrieving revision 1.130 diff -u -r1.130 AUTHORS --- AUTHORS 19 Oct 2008 12:04:12 - 1.130 +++ AUTHORS 19 Jan 2009 06:18:20 - @@ -15,6 +15,7 @@ StartShaded style option. Introduce the command expansion placeholder: $[w.visiblename] Make style matching honour a window's visible name (c.f. $[w.visiblename]) +StartMaximized style option. Serge (gentoosiast) Koksharov: Documentation fixes, bug fixes. Index: ChangeLog === RCS file: /home/cvs/fvwm/fvwm/ChangeLog,v retrieving revision 1.3061 diff -u -r1.3061 ChangeLog --- ChangeLog 30 Dec 2008 13:32:40 - 1.3061 +++ ChangeLog 19 Jan 2009 06:19:11 - @@ -1,3 +1,12 @@ +2008-12-30 Thomas Adam thomas.ada...@gmail.com + + * fvwm/add_window.c (AddWindow): + * fvwm/fvwm.h: + * fvwm/session.h: + * fvwm/style.c: + * fvwm/style.h: + Allow for StartMaximized as a style option. + 2008-12-29 Alexandre Julliard julli...@winehq.org * fvwm/ewmh_events.c (ewmh_WMStateMaxHoriz): Index: NEWS === RCS file: /home/cvs/fvwm/fvwm/NEWS,v retrieving revision 1.767 diff -u -r1.767 NEWS --- NEWS 30 Dec 2008 13:32:40 - 1.767 +++ NEWS 19 Jan 2009 06:19:15 - @@ -7,6 +7,9 @@ * New features: + - New style option StartMaximized for maximizing a window when it is + initially mapped. + - New extended variable $[w.visiblename] Index: doc/commands/Style.xml === RCS file: /home/cvs/fvwm/fvwm/doc/commands/Style.xml,v retrieving revision 1.9 diff -u -r1.9 Style.xml --- doc/commands/Style.xml19 Oct 2008 12:04:13 - 1.9 +++ doc/commands/Style.xml19 Jan 2009 06:20:01 - @@ -76,7 +76,7 @@ emphasis remap='I'StickyAcrossDesks/emphasis / emphasis remap='I'!StickyAcrossDesks/emphasis, emphasis remap='I'!StickyStippledTitle/emphasis / emphasis remap='I'StickyStippledTitle/emphasis, emphasis remap='I'!StickyStippledIconTitle/emphasis / emphasis remap='I'StickyStippledIconTitle/emphasis, -emphasis remap='I'StartIconic/emphasis / emphasis remap='I'StartNormal/emphasis, +emphasis remap='I'StartIconic/emphasis / emphasis remap='I'StartMaximized/emphasis / emphasis remap='I'StartNormal/emphasis, emphasis remap='I'Color/emphasis, emphasis remap='I'ForeColor/emphasis, emphasis remap='I'BackColor/emphasis, emphasis remap='I'Colorset/emphasis, emphasis remap='I'HilightFore/emphasis, emphasis remap='I'HilightBack/emphasis, emphasis remap='I'HilightColorset/emphasis, emphasis remap='I'BorderColorset/emphasis, emphasis remap='I'HilightBorderColorset/emphasis, @@ -1120,6 +1120,10 @@ fvwmopt cmd=Style opt=StartNormal/ style./para +paraIf the style fvwmopt cmd=Style opt=StartMaximized/ is used, then +the window is maximized. Note that this option can accept the same +arguments as the fvwmref cmd=Maximize/ command./para + parafvwmopt cmd=Style opt=StickyIcon/ makes the window sticky when its iconified. It de-iconifies on top the active desktop. Index: fvwm/add_window.c === RCS file: /home/cvs/fvwm/fvwm/fvwm/add_window.c,v retrieving revision 1.398 diff -u -r1.398 add_window.c ---
Re: PATCH: StartMaximized
Hello -- 2009/1/22 Dominik Vogt dominik.v...@gmx.de: On Mon, Jan 19, 2009 at 06:47:28AM +, Thomas Adam wrote: I've been toying around with this patch for a while now, which seems to work. Given that we have PositionPlacement which allows for placingwindows at a specific location, StartMaximized will start a window maximized, allowing for the usual arguments per the Maximize command[1]. For instance: Style somewindow PositionPlacement 0 50, \ StartMaximized growonlayers $[w.layer] -1 grow grow Or more simply: Style somewindow StartMaximized Does the new style take the same arguments as the maximize command, or does it have a different syntax? No, it has the same syntax as the Maximize command -- but as noted as more of a throwaway comment in my email, it does no error checking, so you can do: Maximize 100, 100, grow sdhjfdjkkjdfhkjhdfkjhkdfj And it will still work. :) But that's by-the-by at this point. Comments/suggestions welcome. I ponder if we shouldn't have a much more generic mechanism here. At the moment we have: StartsOnDesk/Page/Screen StartsLowered/Raised StartsShaded StartIconic/Normal All of these could be replaced by a hypothetic style InitWindowCommand (stupid name, suggestions welcome): Yes. When I came up with StartMaximized, I was *really* tempted to add it in as some form of option to PositionPlacement, but it wasn't logical to do so. If we could amalgamate the above list (with perhaps some others -- squashing in my idea for StartMaximized) then that would be a nice idea, and one I would be happy to work on. Style Foo MapFooFunc AddToFunc MapFooFunc + I MoveToPage 1 1 + I Iconify true This way, it would even be possible to get these stupid Open Office windows under control that shade themselves on startup. I am not following you here. What's the relationship between MapFooFunc and InitWindowCommand? Are you implying it's a hook for a known function to be called when the window is mapped? (If this is a silly question to ask, it's because I've yet to have coffee. :P) Of course the parsing would be difficult if the command contains commas. Hmm, yes it would. But we could ignore that for now and just opt for a proof-of-concept. :) -- Thomas Adam
Re: PATCH: StartMaximized
2009/1/22 Dominik Vogt dominik.v...@gmx.de: On Thu, Jan 22, 2009 at 09:01:44AM +, Thomas Adam wrote: 2009/1/22 Dominik Vogt dominik.v...@gmx.de: Style Foo MapFooFunc AddToFunc MapFooFunc + I MoveToPage 1 1 + I Iconify true This way, it would even be possible to get these stupid Open Office windows under control that shade themselves on startup. I am not following you here. What's the relationship between MapFooFunc and InitWindowCommand? Er, I wanted to type Style Foo InitWindowCommand MapFooFunc Ah ha. And suddenly all becomes clear. I shall come up with something soon enough for review. Should be fun. -- Thomas Adam
