Re: FVWM: Events when windows close?
2010/8/10 Michael Großer : > The problem: If I switch to another viewport and then > back to the prior one, then sometimes no window has the > focus. If I give a window a focus and close it, then > again no window has the focus. > > How can I solve this problem? You can't. > My idea is that I use an event to use the "Next" command > to give some window the focus: > - If I switch the viewport, I could call such a function > - If a window closes, I could call such a function. So you want something like this then: DestroyModuleConfig a:* *a: new_page SomeFunc *a: new_desk SomeFunc AddToFunc StartFunction I Module FvwnEvent a DestroyFunc SomeFunc AddToFunc SomeFunc + I None (Focused) Next (AcceptsFocus, !Focused, CurrentPage) FlipFocus > Problem: > - Doing something if I switch the viewport, could be possible. > - But, doing something if a window closes, is difficult. No it isn't -- see FvwmEvent, with the "destroy_window" condition. -- Thomas Adam
Re: FVWM: Events when windows close?
Hi! Thank you very much. This "destroy_window" event could be the solution I was looking for. I will try to solve my problem over the weekend. I like software that is flexible enough to satisfy all my wishes in my role as a user. I wish I had recognized the power of fvwm many years earlier. Michael Thomas Adam wrote: > 2010/8/10 Michael Großer : >> The problem: If I switch to another viewport and then >> back to the prior one, then sometimes no window has the >> focus. If I give a window a focus and close it, then >> again no window has the focus. >> >> How can I solve this problem? > > You can't. > >> My idea is that I use an event to use the "Next" command >> to give some window the focus: >> - If I switch the viewport, I could call such a function >> - If a window closes, I could call such a function. > > So you want something like this then: > > DestroyModuleConfig a:* > *a: new_page SomeFunc > *a: new_desk SomeFunc > > AddToFunc StartFunction I Module FvwnEvent a > > DestroyFunc SomeFunc > AddToFunc SomeFunc > + I None (Focused) Next (AcceptsFocus, !Focused, CurrentPage) FlipFocus > >> Problem: >> - Doing something if I switch the viewport, could be possible. >> - But, doing something if a window closes, is difficult. > > No it isn't -- see FvwmEvent, with the "destroy_window" condition. > > -- Thomas Adam > >
Re: FVWM: Events when windows close?
On Wed, Aug 11, 2010 at 11:37:51AM +0200, Michael Großer wrote: > Hi! > > Thank you very much. This "destroy_window" event could > be the solution I was looking for. > > I will try to solve my problem over the weekend. AFAICT there's nothing left to solve? Oh, and do not top-post on this list, please. -- Thomas Adam
Re: FVWM: Events when windows close?
Thomas Adam wrote: > On Wed, Aug 11, 2010 at 11:37:51AM +0200, Michael Großer wrote: >> Hi! >> >> Thank you very much. This "destroy_window" event could >> be the solution I was looking for. >> >> I will try to solve my problem over the weekend. > > AFAICT there's nothing left to solve? > I need time. Yesterday, a whole day elapsed while I was reading, learning and programming all around fvwm. It is addictive: Once I start tweaking my GUI, I sink into this world and forget the time (and this is bad, because I have a job, too). But, the results are great, compared to the fact that I seriously started my private research project yesterday in the early morning. I have 12 desktops with 12 viewports per desktop. At the bottom left corner on my screen resides the FvwmPager showing 48 viewports at one time (Desk 1 to Desk 4). If I go to desk 5 to desk 8, it shows desk 5 to desk 8. If I go to desk 9 to desk 12, it shows desk 9 to desk 12. So, I have plenty of space for all my different projects. I configured a lot of bindings so I can use the keyboard to create new windows or operate with the viewports. I studied the sample config files of the fvwm95 project to get suggestions. I created a digital clock at the bottom right corner of my screen using 3 instances of xclock to let it show me the day of the week (1st instance), the date (2nd instance) and the time (3rd instance). Fvwm is automatically positioning these instances for me using "Wait" and "Prev" and setting some styles. Later, I will fix the focus problem (I asked for in this mailing list) and I will build a task bar for me at the bottom, where is still some room in the middle. I think that the fvwm95 project will show me how I can get such a task bar. The documentation of the fvwm project is hard to read and could be written a bit more well-arranged. But, I understand the stuff that is written in the documentation, because I invest the time to read it carefully and to make some tests on my system. And, many other window managers do not have to write such a complex documentation, because these window managers have very close limits. And where nothing is to be documented (because of the lack of functionality), there is no complex documentation needed. My goal is to create the perfect desktop user interface for Linux systems and I deeply prefer functionality. If I want a system with 144 desktops, viewports or whatever, then I do not expect that a piece of software wants to explain me that 20 Desktops are enough. If I need a pager that is capable to show the desktops using an arbitrary number of rows, then I am annoyed when I discover that the maintainers of a window manager are about to replace a good but not very inspiring pager by a pager that cannot even use more than 2 rows to display the desktops. So, the most important requirement for me is software with almost no limits regarding functionality. Fvwm is nearly a programming language. And this is what I like. Michael
Re: FVWM: Events when windows close?
On Wed, Aug 11, 2010 at 01:23:43PM +0200, Michael Großer wrote: > space for all my different projects. I configured > a lot of bindings so I can use the keyboard to > create new windows or operate with the viewports. > I studied the sample config files of the fvwm95 > project to get suggestions. I created a digital Why? You won't learn anything from looking at that file -- it's very old. > clock at the bottom right corner of my screen > using 3 instances of xclock to let it show > me the day of the week (1st instance), the > date (2nd instance) and the time (3rd instance). > Fvwm is automatically positioning these > instances for me using "Wait" and "Prev" > and setting some styles. Wait and Prev? Hmm, see the following as to why this is not a good thing anymore: http://fvwmwiki.xteddy.org/Tips/FVWMStartupProcedure/ > Later, I will fix the focus problem (I asked > for in this mailing list) and I will build a > task bar for me at the bottom, where is still > some room in the middle. I think that the > fvwm95 project will show me how I can get such > a task bar. The documentation of the fvwm > project is hard to read and could be written > a bit more well-arranged. But, I understand > the stuff that is written in the documentation, How could it be improved? [...] -- Thomas Adam
Re: FVWM: Events when windows close?
Thomas Adam wrote: > On Wed, Aug 11, 2010 at 01:23:43PM +0200, Michael Großer wrote: >> space for all my different projects. I configured >> a lot of bindings so I can use the keyboard to >> create new windows or operate with the viewports. >> I studied the sample config files of the fvwm95 >> project to get suggestions. I created a digital > > Why? You won't learn anything from looking at that file -- it's very old. To get a clue how things work. The man pages have the theory and the fvwm95 config files contain the practice and can immediately be tested. In other words: The man pages are the reference and the fvwm95 config files are an example. But 90 percent of my own config files is code that I checked against the man pages, because I actually want to understand my own code. >> clock at the bottom right corner of my screen >> using 3 instances of xclock to let it show >> me the day of the week (1st instance), the >> date (2nd instance) and the time (3rd instance). >> Fvwm is automatically positioning these >> instances for me using "Wait" and "Prev" >> and setting some styles. > > Wait and Prev? Hmm, see the following as to why this is not a good thing > anymore: > > http://fvwmwiki.xteddy.org/Tips/FVWMStartupProcedure/ I will look at it later. >> Later, I will fix the focus problem (I asked >> for in this mailing list) and I will build a >> task bar for me at the bottom, where is still >> some room in the middle. I think that the >> fvwm95 project will show me how I can get such >> a task bar. The documentation of the fvwm >> project is hard to read and could be written >> a bit more well-arranged. But, I understand >> the stuff that is written in the documentation, > > How could it be improved? > Some examples: 1. FuncFvwmRaiseLowerX == This page... http://www.fvwm.org/doc/unstable/fvwm/fvwm.man.html ... does not explain, how FuncFvwmRaiseLowerX exactly works. I just use it and I don't understand it. I just use it to move windows with "Win" + "left mouse button" and it does the job for me. I don't now why. This could be improved. Perhaps just make a link to the document that gives more information about FuncFvwmRaiseLowerX. 2. destroy_window = This page... http://www.fvwm.org/documentation/manpages/unstable/FvwmEvent.php ... mentions "destroy_window" only two times. I can guess what it does, and I think, I will solve my problems with this, but one little section for each event that explains what exactly causes the respective event, would be a nice improvement. 3. continuous text == The human race is an image processing animal. When I was studying the bindings syntax, I needed a reference. I needed the particular options in tables. But, I found them amongst continuous text. The first thing that I did was creating my own reference (half German, half English) that I attached to this e-mail message. Just look at the attachments to guess what I mean. I thing, it could be a nice improvement if someone would write this kind of information in table form, so I can find the right piece of information more quickly (and without the need to create my own reference in my own language). You asked for this kind of feedback. I hope, I could give you a good and constructive answer for the start. For me, I think, I got some first acceptable results with fvwm. But, I think that I need some years to be an absolute fvwm professional. I'm just learning. Michael Syntax der Bindings === 1. Tastatur-Bindings Key Keyname Context Modifiers Function 2. Maus-Bindings Mouse Button Context Modifiers Function 3. Der "Keyname" Siehe hier: /usr/include/X11/keysymdef.h --> Das "XK_" muss weggelassen werden. 4. Der "Button" --- 0: Irgendeine Maustaste 1: Linke Maustaste 2: Mittlere Maustaste 3: Rechte Maustaste 5. Der "Context" Wo soll das Binding zur Anwendung kommen? R: the root window W: an application window T: a window title-bar S: a window side, top or bottom bar F: a window frame (the corners) I: an icon window 0: title-bar button Nummer 0 . . . 9: title-bar button Nummer 9 A: any context except for title-bar buttons Kombinationen dieser Buchstaben und Zahlen sind möglich. 6. Die "Modifiers" -- N: no modifiers C: Control S: Shift M: Meta = Alt L: Caps-Lock (wird per Default ignoriert) A: Any modifier 0: = no modifiers 1: mod1 = Alt 2: mod2 3: mod3 4: mod4 = Win 5: mod5 = Alt Gr 7. Function --- 8. Title-bar buttons 1 3 5 7 9 0 8 6 4 2 1. StartFunction Wird bei Starts und Restarts aufgerufen. 2. InitFunction === Wird bei Starts aufgerufen, direkt nach "StartFunction". 3. RestartFunction == Wird bei Restarts aufgerufen, direkt nach "StartFunction". 4. Einklinken von Befehlen in diese Funktionen
Re: FVWM: Events when windows close?
On Wed, Aug 11, 2010 at 02:27:25PM +0200, Michael Großer wrote: > Thomas Adam wrote: > > On Wed, Aug 11, 2010 at 01:23:43PM +0200, Michael Großer wrote: > >> space for all my different projects. I configured > >> a lot of bindings so I can use the keyboard to > >> create new windows or operate with the viewports. > >> I studied the sample config files of the fvwm95 > >> project to get suggestions. I created a digital > > > > Why? You won't learn anything from looking at that file -- it's very old. > > To get a clue how things work. The man pages > have the theory and the fvwm95 config files > contain the practice and can immediately be > tested. In other words: The man pages are the > reference and the fvwm95 config files are an > example. But 90 percent of my own config files > is code that I checked against the man pages, > because I actually want to understand my > own code. Sure -- and it's not your fault, it's just that to solve this "problem" properly, requires a lot more effort/changes than simply updating the config file to reflect newer changes in syntax, etc. That has only been half-heartedly done recently -- there's a lot of crap still in there which either needs to be removed, or updated. Note that I am not talking about the fvwm95 example file specifically, but about the config files installed via FvwmFormSetup. That's a big contention point historically in FVWM though. :) > Some examples: > > 1. FuncFvwmRaiseLowerX > == > This page... > http://www.fvwm.org/doc/unstable/fvwm/fvwm.man.html > ... does not explain, how FuncFvwmRaiseLowerX exactly > works. I just use it and I don't understand it. > I just use it to move windows with > "Win" + "left mouse button" and it does the > job for me. I don't now why. This could be > improved. Perhaps just make a link to the > document that gives more information about > FuncFvwmRaiseLowerX. By default, it looks like this: AddToFunc FuncFvwmRaiseLowerX + I Raise + M $0 + D Lower And is invoked (by default) like this: Mouse 1 T A FuncFvwmRaiseLowerX Move Mouse 1 FS A FuncFvwmRaiseLowerX Resize Mouse 2 FST A FuncFvwmRaiseLowerX Move Hence, what this function does is wrap two similar functionalities together. * Whenever the function is run on a window (+ I) it's raised -- always. * If the window is moved (+M) then the action passed into that function is called -- so in the above example, we have a choice of either "Move" or "Resize" depending on the binding. * If the user double-clicks (either on the Title (T), Frames (F) or Sides (S), then the window is lowered. In the link to the fvwmwiki article I gave you, I explain where this function is defined, and why it's not "accessible" to the user, and why they have to redefine it for themselves. But I take your point that there is little documentation on what the function does, but its definition is in "man fvwm". I will look at improving this later on this evening. > 2. destroy_window > = > This page... > http://www.fvwm.org/documentation/manpages/unstable/FvwmEvent.php > ... mentions "destroy_window" only two times. > I can guess what it does, and I think, I will > solve my problems with this, but one little section > for each event that explains what exactly causes > the respective event, would be a nice improvement. Note also -- there is this rather idiotic thread: http://www.mail-archive.com/fvwm@fvwm.org/msg00949.html But take away from that post that some of the information you're wanting -- whilst useful -- might be adding bloat. In your case, are you saying for FvwmEvent you want an explanation of what each event does, and when it's triggered? I could add that, but assumed the names themselves are self-documenting. Again -- can you provide an example using "destroy_window" what sort of information you're wanting to see? > 3. continuous text > == > The human race is an image processing animal. > When I was studying the bindings syntax, I needed > a reference. I needed the particular options > in tables. But, I found them amongst continuous text. > The first thing that I did was creating my own > reference (half German, half English) that > I attached to this e-mail message. I am *especially* keen on this sort of information because of the impending 2.6.0 release. I have no problems delaying FVWM further if this sort of thing is going to be useful; *but* making the data tabular also might lose readability in things like man page formats. You are aware we have HTML documentation which fragments the monolithic manpage, right? http://fvwm.org/doc/unstable/index.html > Just look at the attachments to guess what I mean. Sorry, I don't speak German. But if you can be more specific about which areas you think would benefit from tabulating information, I am happy to work with you to accomplish this. I've been banging on for *years* about this sort of thing, and finally it might actually happen. :) You've made my day.
Re: FVWM: Events when windows close?
Thomas Adam wrote: > On Wed, Aug 11, 2010 at 02:27:25PM +0200, Michael Großer wrote: > >> 2. destroy_window >> = >> This page... >> http://www.fvwm.org/documentation/manpages/unstable/FvwmEvent.php >> ... mentions "destroy_window" only two times. >> I can guess what it does, and I think, I will >> solve my problems with this, but one little section >> for each event that explains what exactly causes >> the respective event, would be a nice improvement. > > Note also -- there is this rather idiotic thread: > > http://www.mail-archive.com/fvwm@fvwm.org/msg00949.html > > But take away from that post that some of the information you're wanting -- > whilst useful -- might be adding bloat. In your case, are you saying for > FvwmEvent you want an explanation of what each event does, and when it's > triggered? I could add that, but assumed the names themselves are > self-documenting. > > Again -- can you provide an example using "destroy_window" what sort of > information you're wanting to see? Such kind of information could be nice: - destroy_window: --> Generates an event if a window disappears. - res_class: --> What exactly causes this event? (I don't know) - res_name: --> What exactly causes this event? (I don't know) So, a list would be fine that mentions this kind of information: - event name - what exactly causes the event - event name - what exactly causes the event - event name - what exactly causes the event - ... - ... - ... - and so on > >> 3. continuous text >> == >> The human race is an image processing animal. >> When I was studying the bindings syntax, I needed >> a reference. I needed the particular options >> in tables. But, I found them amongst continuous text. >> The first thing that I did was creating my own >> reference (half German, half English) that >> I attached to this e-mail message. > > I am *especially* keen on this sort of information because of the impending > 2.6.0 release. I have no problems delaying FVWM further if this sort of > thing is going to be useful; *but* making the data tabular also might lose > readability in things like man page formats. Give it a try. > > You are aware we have HTML documentation which fragments the monolithic > manpage, right? > > http://fvwm.org/doc/unstable/index.html Now, I am ware of this, beaus you pointed this out ;-) >> Just look at the attachments to guess what I mean. > > Sorry, I don't speak German. But if you can be more specific about which > areas you think would benefit from tabulating information, I am happy to > work with you to accomplish this. Look at this: http://www.fvwm.org/doc/unstable/fvwm/fvwm.man.html#menus 31.1.13. Menu The orange color of the headwords and then the documentation in black color is a good start. Now, look here: http://fvwm.org/doc/unstable/commands/Mouse.html Read this text: > Context describes where the binding applies. Valid > contexts are 'R' for the root window, 'W' for an > application window, 'D' for a desktop application > (as kdesktop or Nautilus desktop), 'T' for a window > title-bar, 'S' for a window side, top, or bottom bar, > '[', ']', '-' and '_' for the left, right, top or > bottom side only, 'F' for a window frame (the corners), > '<', '^', '>' and 'v' for the top left, top right, > bottom right or bottom left corner, 'I' for an icon > window, or '0' through '9' for title-bar buttons, > or any combination of these letters. 'A' is for > any context. For instance, a context of "FST" > applies when the mouse is anywhere in a window's > border except the title-bar buttons. Only 'S' and > 'W' are valid for an undecorated window. Now, read this text: Context --- It describes where the binding applies. Valid contexts are: - 'R' for the root window - 'W' for an application window - 'D' for a desktop application (as kdesktop or Nautilus desktop) - 'T' for a window title-bar - 'S' for a window side, top, or bottom bar - '[' the left bottom side only - ']' the right side only - '-' the top side only - '_' the bottom side only - 'F' for a window frame (the corners) - '<' for the top left corner - '^' for the top corner - '>' for the top bottom right corner - 'v' for the top bottom left corner - 'I' for an icon window - '0' through '9' for title-bar buttons - any combination of these letters are possible too - 'A' is for any context Example --- A context of "FST" applies when the mouse is anywhere in a window's border except the title-bar buttons. Only 'S' and 'W' are valid for an undecorated window. I quickly hacked my version of the text just now, but perhaps you could see that now it is a lot easier to read my version of the text. Give it a further improve and as the result you should have a text that suits both HTML pages and classic man pages. For this hack, I chose the list form. The table form would also be good idea. It doesn't matter if you choose the list form or the table form as long
Re: FVWM: Events when windows close?
On Wed, Aug 11, 2010 at 04:19:20PM +0200, Michael Großer wrote: > Thomas Adam wrote: > > On Wed, Aug 11, 2010 at 02:27:25PM +0200, Michael Großer wrote: > > > >> 2. destroy_window > >> = > >> This page... > >> http://www.fvwm.org/documentation/manpages/unstable/FvwmEvent.php > >> ... mentions "destroy_window" only two times. > >> I can guess what it does, and I think, I will > >> solve my problems with this, but one little section > >> for each event that explains what exactly causes > >> the respective event, would be a nice improvement. > > > > Note also -- there is this rather idiotic thread: > > > > http://www.mail-archive.com/fvwm@fvwm.org/msg00949.html > > > > But take away from that post that some of the information you're wanting -- > > whilst useful -- might be adding bloat. In your case, are you saying for > > FvwmEvent you want an explanation of what each event does, and when it's > > triggered? I could add that, but assumed the names themselves are > > self-documenting. > > > > Again -- can you provide an example using "destroy_window" what sort of > > information you're wanting to see? > > Such kind of information could be nice: > > - destroy_window: > --> Generates an event if a window disappears. Well, nothing generates these events from FvwmEvent's point of view -- FvwmEvent will just react to events -- but I take your point, they could be explained better. > Look at this: > http://www.fvwm.org/doc/unstable/fvwm/fvwm.man.html#menus > 31.1.13. Menu > The orange color of the headwords and then the documentation > in black color is a good start. That's a CSS issue only from the resulting HTML output. The documentation itself is single-sourced in a monstrous mess of docbook XML (which **will** be changing in 2.6.0 -- it's just fucking abysmal to keep it the way it is for much longer. That's a promise) -- so what we change will affect not only the HTML, but the man page as well. > Now, look here: > http://fvwm.org/doc/unstable/commands/Mouse.html > > Read this text: > > Context describes where the binding applies. Valid > > contexts are 'R' for the root window, 'W' for an > > application window, 'D' for a desktop application > > (as kdesktop or Nautilus desktop), 'T' for a window > > title-bar, 'S' for a window side, top, or bottom bar, > > '[', ']', '-' and '_' for the left, right, top or > > bottom side only, 'F' for a window frame (the corners), > > '<', '^', '>' and 'v' for the top left, top right, > > bottom right or bottom left corner, 'I' for an icon > > window, or '0' through '9' for title-bar buttons, > > or any combination of these letters. 'A' is for > > any context. For instance, a context of "FST" > > applies when the mouse is anywhere in a window's > > border except the title-bar buttons. Only 'S' and > > 'W' are valid for an undecorated window. > > Now, read this text: > > Context > --- > It describes where the binding applies. Valid contexts are: > - 'R' for the root window > - 'W' for an application window > - 'D' for a desktop application (as kdesktop or Nautilus > desktop) Yes. OK. Point taken. Shouldn't be too difficult to do. > For this hack, I chose the list form. The > table form would also be good idea. It doesn't > matter if you choose the list form or the table > form as long as you break up this continuous text > form that is hard to read. Tables I think. They translate into groff much easier. > It could help to keep the orange color of the > letters because the more color, the more eye catching > is the relevant information. In terms of HTML, yes. That won't change, but manpages are a different kettle of fish. > * context > * modifiers > * focus policies OK. No problems. I will look at this later on when I get back from work. -- Thomas Adam
Re: FVWM: Events when windows close?
Thomas Adam wrote:
> On Wed, Aug 11, 2010 at 04:19:20PM +0200, Michael Großer wrote:
>> Thomas Adam wrote:
>> > On Wed, Aug 11, 2010 at 02:27:25PM +0200, Michael Großer wrote:
>> >
>> >> 2. destroy_window
>> >> =
>> >> This page...
>> >> http://www.fvwm.org/documentation/manpages/unstable/FvwmEvent.php
>> >> ... mentions "destroy_window" only two times.
>> >> I can guess what it does, and I think, I will
>> >> solve my problems with this, but one little section
>> >> for each event that explains what exactly causes
>> >> the respective event, would be a nice improvement.
>> >
>> > Note also -- there is this rather idiotic thread:
>> >
>> > http://www.mail-archive.com/fvwm@fvwm.org/msg00949.html
>> >
>> > But take away from that post that some of the information you're wanting --
>> > whilst useful -- might be adding bloat. In your case, are you saying for
>> > FvwmEvent you want an explanation of what each event does, and when it's
>> > triggered? I could add that, but assumed the names themselves are
>> > self-documenting.
>> >
>> > Again -- can you provide an example using "destroy_window" what sort of
>> > information you're wanting to see?
>>
>> Such kind of information could be nice:
>>
>> - destroy_window:
>> --> Generates an event if a window disappears.
>
> I started this for FvwmEvent -- you can see the changes to the manpage here:
>
> http://github.com/ThomasAdam/fvwm/commit/49a53ee408cba26f7649fc4b56df0d309b485cfd
>
> Run that file through "man" -- see the table produced. Is that what you
> were after?
>
> -- Thomas Adam
>
I cannot find any displayable man page.
But, I found some kind of source file named "FvwmEvent.1.in".
There, I found:
> T{
> destroy_window
> T}
> @T{
> Runs when a window is closed.
> T}
> _
Yes. This is a good start. Now, the reader is not
guessing but reading and knowing. There is difference between
the one case, where the reader guesses and the other case,
where the reader knows the facts because they are written
down by the author.
> T{
> res_class
> T}
> @T{
> Runs when the WM_CLASS property of a window changes.
> T}
> _
> T{
> res_name
> T}
> @T{
> Runs when the WM_CLASS property of a window changes (for the resource).
> T}
> _
Are you sure that a WM_CLASS property causes both the res_class
and the res_name event? I don't know so much about this WM_XXX stuff,
but if I think logically, shouldn't it mean WM_NAME in the
second event? If not, what is the difference between
res_class and res_name? Why two events have to exist? Why
not one? Or is one of them an alias of the other?
Michael
Re: FVWM: Events when windows close?
On Thu, Aug 12, 2010 at 10:03:01AM +0200, Michael Großer wrote: > I cannot find any displayable man page. > But, I found some kind of source file named "FvwmEvent.1.in". > There, I found: Download the file -- the direct link to the raw file is here: http://github.com/ThomasAdam/fvwm/raw/49a53ee408cba26f7649fc4b56df0d309b485cfd/modules/FvwmEvent/FvwmEvent.1.in Then you have to actually run "man" over it: man ./FvwmEvent.1.in I am especially keen for you to do this, so I can ensure my troff skills are still OK. I know troff fairly well. :) > Are you sure that a WM_CLASS property causes both the res_class > and the res_name event? I don't know so much about this WM_XXX stuff, > but if I think logically, shouldn't it mean WM_NAME in the > second event? If not, what is the difference between > res_class and res_name? Why two events have to exist? Why > not one? Or is one of them an alias of the other? No, I mean WM_CLASS -- that holds two properties therein: The resource name and the class name. Go see the ICCCM2. -- Thomas Adam
Re: FVWM: Events when windows close?
On Wed, Aug 11, 2010 at 04:19:20PM +0200, Michael Großer wrote: > Thomas Adam wrote: > > On Wed, Aug 11, 2010 at 02:27:25PM +0200, Michael Großer wrote: > > > >> 2. destroy_window > >> = > >> This page... > >> http://www.fvwm.org/documentation/manpages/unstable/FvwmEvent.php > >> ... mentions "destroy_window" only two times. > >> I can guess what it does, and I think, I will > >> solve my problems with this, but one little section > >> for each event that explains what exactly causes > >> the respective event, would be a nice improvement. > > > > Note also -- there is this rather idiotic thread: > > > > http://www.mail-archive.com/fvwm@fvwm.org/msg00949.html > > > > But take away from that post that some of the information you're wanting -- > > whilst useful -- might be adding bloat. In your case, are you saying for > > FvwmEvent you want an explanation of what each event does, and when it's > > triggered? I could add that, but assumed the names themselves are > > self-documenting. > > > > Again -- can you provide an example using "destroy_window" what sort of > > information you're wanting to see? > > Such kind of information could be nice: > > - destroy_window: > --> Generates an event if a window disappears. I started this for FvwmEvent -- you can see the changes to the manpage here: http://github.com/ThomasAdam/fvwm/commit/49a53ee408cba26f7649fc4b56df0d309b485cfd Run that file through "man" -- see the table produced. Is that what you were after? -- Thomas Adam
Re: FVWM: Events when windows close?
> On Thu, Aug 12, 2010 at 10:03:01AM +0200, Michael Großer wrote: > > I cannot find any displayable man page. > > But, I found some kind of source file named "FvwmEvent.1.in". > > There, I found: > > Download the file -- the direct link to the raw file is here: > > http://github.com/ThomasAdam/fvwm/raw/49a53ee408cba26f7649fc4b56df0d309b485cfd/modules/FvwmEvent/FvwmEvent.1.in > > Then you have to actually run "man" over it: > > man ./FvwmEvent.1.in > > I am especially keen for you to do this, so I can ensure my troff skills > are > still OK. I know troff fairly well. :) Yeah, now I see it. I have to enter > man ./FvwmEvent.1.in to see the man page. If I only enter > man FvwmEvent.1.in then I see nothing, because the "./" is essential... Well, I see a table with the events and the triggers. This is good. Well done. > > Are you sure that a WM_CLASS property causes both the res_class > > and the res_name event? I don't know so much about this WM_XXX stuff, > > but if I think logically, shouldn't it mean WM_NAME in the > > second event? If not, what is the difference between > > res_class and res_name? Why two events have to exist? Why > > not one? Or is one of them an alias of the other? > > No, I mean WM_CLASS -- that holds two properties therein: > > The resource name and the class name. Go see the ICCCM2. > Here I still think, that someting is wrong. I looked at ICCCM2 http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.2.5 http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.2.1 and detected that two properties WM_CLASS and WM_NAME are existing. In your new man page, I see: * res_class --> WM_CLASS * res_name --> WM_CLASS Why not "res_name --> WM_NAME"? I cannot see the logic... Michael
Re: FVWM: Events when windows close?
On Thu, Aug 12, 2010 at 03:59:26PM +0200, michael.gros...@gmx.de wrote: > Why not "res_name --> WM_NAME"? > I cannot see the logic... That's because it's not meant to be easy to understand by those who aren't programmers, I suppose. I'll reiterate it again for you though. The WM_CLASS XAtom has two properties: a resource name, and a class name. What you're looking for is already present in the window_name event, which I even documented as such. :P You need not concern yourself with them -- note that the WM_CLASS is special though (and likely own applies to windows in the Withdrawn state) because that's the only time the window class can be updated. So this event is rather specific. I'd rather you concentrated on something more useful, Michael, to be honest. :) -- Thomas Adam
Re: FVWM: Events when windows close?
On Thu, Aug 12, 2010 at 08:19:10AM +0100, Thomas Adam wrote:
> I started this for FvwmEvent -- you can see the changes to the manpage here:
>
> http://github.com/ThomasAdam/fvwm/commit/49a53ee408cba26f7649fc4b56df0d309b485cfd
>
> Run that file through "man" -- see the table produced. Is that what you
> were after?
Same question, really. What were your thoughts on my attempt at cleaning up
the FvwmEvent man page?
It's moot for the format, given my Asciidoc work but I never heard anything
back on this and I'm sick of seeing it on my TODO list which isn't getting
any shorter.
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
Re: FVWM: Events when windows close?
Thomas Adam wrote: > On Thu, Aug 12, 2010 at 08:19:10AM +0100, Thomas Adam wrote: >> I started this for FvwmEvent -- you can see the changes to the manpage here: >> >> http://github.com/ThomasAdam/fvwm/commit/49a53ee408cba26f7649fc4b56df0d309b485cfd >> >> Run that file through "man" -- see the table produced. Is that what you >> were after? > > Same question, really. What were your thoughts on my attempt at cleaning up > the FvwmEvent man page? > > It's moot for the format, given my Asciidoc work but I never heard anything > back on this and I'm sick of seeing it on my TODO list which isn't getting > any shorter. > > -- Thomas Adam Hi Thomas, one of the ideas of this thread was that I noticed a list of FvwmEvents without explanations for the most events. You revised this man-page and sent a link to your revision. After explaining me how I can display man pages when they are a file, I finally was able to view your revision. You created a table, in which you wrote an explanation for each FvwmEvent: http://github.com/ThomasAdam/fvwm/raw/49a53ee408cba26f7649fc4b56df0d309b485cfd/modules/FvwmEvent/FvwmEvent.1.in My reaction to this table on 2010-08-12, at 03:59 pm was: > Well, I see a table with the events and the triggers. > This is good. Well done. This table with the explanations is good. In case you didn't made an official man page version out of that draft, I think you should do it now. You really did what I expected: Writing an explanation to each item of the list. Our conversation drifted into a direction where I stated that I didn't understand the difference between "res_class" and "res_name". You answered that only programmers are supposed to understand the documentation related to "res_class" and "res_name", and that I should concentrate on something more useful. So, well, I am a programmer, but since I'm not specialized into that context, I cannot determine if your answer regarding "res_class" and "res_name", and the importance of this site, is right or wrong. Usually, I merely send out an alert signal by saying that a documentation contains a statement that I do not understand. It's about you how to interpret that alert signal. Another thing that catched my eye today (in order to improve the quality of this man-page): It contains a statement about an event called "toggle_paging event": > The toggle_paging event will be supported, as soon, as it's > resurrected by fvwm: > > *FvwmEvent: toggle_paging fwop.au This event is absent in the table, and I don't understand the meaning of the quoted statement. If you want to help future FVWM users to understand this toggle_paging event, you could include this event (and all other missing events) into the table too, and describe them. It's a suggestion. Do with my feedback what you want. I recommend to publish at least your ready work. It were a pity if the table based idea would disappear into a secret drawer forever. Any questions to me about that? Since I understand and use the events that I really need now, my original problem is solved. Thank you and best regards, Michael
Re: FVWM: Events when windows close?
Michael Großer writes: > Our conversation drifted into a direction where I stated that > I didn't understand the difference between "res_class" and > "res_name". > > You answered that only programmers are supposed to understand > the documentation related to "res_class" and "res_name", and that > I should concentrate on something more useful. I must have missed this conversation. res_class and res_name are explained in the ICCCM. For our purposes, they are just 2 of the fields Fvwm uses for style matching. Both can be displayed for any window by FvwmIdent. -- Dan Espen
Re: FVWM: Events when windows close?
Dan Espen wrote: > Michael Großer writes: > >> Our conversation drifted into a direction where I stated that >> I didn't understand the difference between "res_class" and >> "res_name". >> >> You answered that only programmers are supposed to understand >> the documentation related to "res_class" and "res_name", and that >> I should concentrate on something more useful. > > I must have missed this conversation. http://www.mail-archive.com/fvwm@fvwm.org/msg01425.html > res_class and res_name are explained in the ICCCM. Thanks! The pieces result into a puzzle that I now begin to understand slowly: http://tronche.com/gui/x/icccm/ http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.2.1 http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.2.5 http://www.jumping-blue-turtle.com/fvwm/will_disappear_on_2012-04-04/name_and_class.png > For our purposes, they are just 2 of the fields Fvwm uses > for style matching. Both can be displayed for any window > by FvwmIdent. > I recommend to recheck this piece of documentation: +-++ |res_class|| | | Runs when the WM_CLASS | | | property of a window | | | changes. | +-++ |res_name || | | Runs when the WM_CLASS | | | property of a window | | | changes (for the | | | resource). | +-++ Since the ICCCM standard clearly contains both a WM_CLASS property and a WM_NAME property, the man-page reader could think that there is an error when WM_CLASS runs "res_class" and WM_CLASS runs "res_name". The man-page should explain why not WM_NAME does run "res_name". Why WM_CLASS? Or is there an error? Consider this action as a kind of quality management ;-) Michael <>
Re: FVWM: Events when windows close?
On Sun, Jan 01, 2012 at 10:06:33PM +0100, Michael Großer wrote:
> I recommend to recheck this piece of documentation:
>
> +-++
> |res_class||
> | | Runs when the WM_CLASS |
> | | property of a window |
> | | changes. |
> +-++
> |res_name ||
> | | Runs when the WM_CLASS |
> | | property of a window |
> | | changes (for the |
> | | resource). |
> +-++
>
> Since the ICCCM standard clearly contains both a
> WM_CLASS property and a WM_NAME property, the man-page
> reader could think that there is an error when
> WM_CLASS runs "res_class" and
> WM_CLASS runs "res_name".
No. They both come from the XClassHint struct. This has nothing to do
with WM_NAME, and the above does not allude to or mention WM_NAME.
> The man-page should explain why not
> WM_NAME does run "res_name". Why WM_CLASS?
See above.
> Or is there an error?
See above.
This event, along with res_name, are only useful for things like
add/configure_window events as that's one of the main times such packets are
sent.
Note that it is forbidden by the ICCCM for the class name to be changed once
the window has left the Withdrawn state.
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
Re: FVWM: Events when windows close?
On Sun, Jan 01, 2012 at 07:17:24PM +0100, Michael Großer wrote:
> This event is absent in the table, and I don't understand the
> meaning of the quoted statement.
Removing it is easier.
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
I revised my clock finally [Re: FVWM: Events when windows close?]
Thomas Adam wrote: > On Wed, Aug 11, 2010 at 01:23:43PM +0200, Michael Großer wrote: >> clock at the bottom right corner of my screen >> using 3 instances of xclock to let it show >> me the day of the week (1st instance), the >> date (2nd instance) and the time (3rd instance). >> Fvwm is automatically positioning these >> instances for me using "Wait" and "Prev" >> and setting some styles. > > Wait and Prev? Hmm, see the following as to why this is not a good thing > anymore: > > http://fvwmwiki.xteddy.org/Tips/FVWMStartupProcedure/ > Today, I revised my "0009_clock" config file: > #AddToFunc StartFunction > AddToFunc InitFunction > + I Schedule 100 Exec exec xclock -digital -update 1 -strftime "%A " > -geometry 200x34-102-0 > + I Schedule 200 Exec exec xclock -digital -update 1 -strftime "%d.%m.%Y" > -geometry 114x34-90-0 > + I Schedule 300 Exec exec xclock -digital -update 1 -strftime "%H:%M:%S > Uhr" -geometry 108x34-0-0 > > > > # The clock is supposed to get styles! > Style xclock Sticky, NoTitle, HandleWidth 0, StaysOnBottom No unstabilising Waits anymore. I use the "-geometry" option now to place the instances onto the right coordinates. And the Schedule command ensures that the clocks start in the right order (the "date" overlays the "day of week", the "time" overlays the "date" (and not the other ways around)). Thanks for the hints. Now it's time to tweak these little details. Michael P.S. If there were an approach to save these additional 200 or 300 milliseconds to get the clocks into the right order (without having to risk FVWM to hang using the "Wait" command), I would be glad about this.
Re: I revised my clock finally [Re: FVWM: Events when windows close?]
Michael Großer wrote:
> No unstabilising Waits anymore. I use the "-geometry" option now to place the
> instances onto the right coordinates. And the Schedule command
> ensures that the clocks start in the right order (the "date" overlays
> the "day of week", the "time" overlays the "date" (and not the other ways
> around)).
>
> Thanks for the hints. Now it's time to tweak these little details.
>
> Michael
>
>
>
> P.S.
> If there were an approach to save these additional 200 or 300 milliseconds
> to get the clocks into the right order (without having to risk FVWM to
> hang using the "Wait" command), I would be glad about this.
Now, my clock is perfect. When the system is fast, the auto correction
should take effect immediately (after 10 or 100 milliseconds).
For slower systems, there is another auto correction after 1 second.
For very slow systems, there is yet another auto correction after 10 seconds:
> AddToFunc InitFunction
> + I Exec exec xclock -digital\
> -update 1\
> -strftime "%A "\
> -geometry 200x34-102-0\
> -name "clock1"
>
> + I Exec exec xclock -digital\
> -update 1\
> -strftime "%d.%m.%Y"\
> -geometry 114x34-90-0\
> -name "clock2"
>
> + I Exec exec xclock -digital\
> -update 1\
> -strftime "%H:%M:%S Uhr"\
> -geometry 108x34-0-0\
> -name "clock3"
>
> AddToFunc StartFunction
> + I Schedule 13 Prev ("clock1") arrange_the_clock
> + I Schedule 103 Prev ("clock1") arrange_the_clock
> + I Schedule 1003 Prev ("clock1") arrange_the_clock
> + I Schedule 10003 Prev ("clock1") arrange_the_clock
>
> + I Schedule 12 Prev ("clock2") arrange_the_clock
> + I Schedule 102 Prev ("clock2") arrange_the_clock
> + I Schedule 1002 Prev ("clock2") arrange_the_clock
> + I Schedule 10002 Prev ("clock2") arrange_the_clock
>
> + I Schedule 11 Prev ("clock3") arrange_the_clock
> + I Schedule 101 Prev ("clock3") arrange_the_clock
> + I Schedule 1001 Prev ("clock3") arrange_the_clock
> + I Schedule 10001 Prev ("clock3") arrange_the_clock
>
>
>
>
>
> # The clock is supposed to get styles!
> Style clock? Sticky, NoTitle, HandleWidth 0, StaysOnBottom, WindowListSkip
>
> # bring the clock instances into the right order
> DestroyFunc arrange_the_clock
> AddToFunc arrange_the_clock
> + I Layer 0 2
> + I Lower
