CVS griph: * BroadcastRestack to modules even if non is done.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: griph 07/01/14 04:36:22 Modified files: . : ChangeLog fvwm : stack.c Log message: * BroadcastRestack to modules even if non is done. * don't do raise hacks if no restack was done. * fix detection of non needed lower operations
cross-referenced FVWM documentation
Hi all, I have been working on converting the FVWM documentation into DocBook format. You can view some preliminary HTML results on-line. http://members.optusnet.com.au/~scott.fvwm/index.html The most interesting links, so far, are: All Commands Grouped Commands Modules FVWM man page Comments/criticism/feedback most welcome. Scott. :)
Re: cross-referenced FVWM documentation
On Sun, 14 Jan 2007, Scott Smedley wrote: Hi all, I have been working on converting the FVWM documentation into DocBook format. You can view some preliminary HTML results on-line. http://members.optusnet.com.au/~scott.fvwm/index.html looking good. The most interesting links, so far, are: All Commands Grouped Commands Modules FVWM man page Comments/criticism/feedback most welcome. ChangeMenuStyle is not deprecated. /Viktor
Re: Bug in FvwmIdent's Geometry string.
On Sun, Jan 14, 2007 at 12:27:35AM +, Thomas Adam wrote: On Sun, Jan 14, 2007 at 12:50:57AM +0100, Dominik Vogt wrote: On Sat, Jan 13, 2007 at 09:12:00PM +, Thomas Adam wrote: On Sat, Jan 13, 2007 at 04:34:17PM +0100, Dominik Vogt wrote: There appears to be a discrepency between how FvwmIdent calculates the geometry of the specified window, in relation to, say, how xwininfo calculates it. In both cases, xwininfo's report of the geometry of a window is correct. You just have to use a test case of: xterm -g some_geometry_string for the numbers from xwininfo and FvwmIdent to see what's happening. I don't have time to look into why at the moment, I wish I did. Fixed. Are you sure? There is a difference in the numbers between the FvwmIdent module shipped with 2.5.19 and the updated on in CVS, but they're still reporting erroneous numbers in the geometry string that I can tell. Um, yes I'm quite sure (apart from the new bug I introduced with the fix. Here's an example: xterm -g 80x24+0+0 Places xterm in the top-left corner of the current page. If you run FvwmIdent (from 2.5.19, say) on that window, you'll get a reported geometry of: 484x316+0+0 That's the geometry in pixels. I'm obviously missing something fundamental here. :) That's what I thought -- but this wouldn't really help a client such as XTerm would it? (which largely depends on resize increments to determine geometry unless one has ResizeHintOverride set, for instance). To my eyes, when I use FvwmIdent to ascertain information about a window, such as its geometry, I'd like to think that when I do: my_app -geometry 100x34+0+0 That it opens up in that location. But it doesn't -- not, if you say, compare it to the output from xwininfo, which, when using its geometry string, does open up the application in the position I would have expected it to. Ideally, shouldn't both xwininfo and FvwmIdent's geometry reporting match? I don't understand what your problem is. When I start xterm like this: $ xterm -g 80x24+0+0 I get an 80x24 xterm at +0+0. FvwmIdent says: X: 0 (frame x position) Y: 0 (frame y position) Width: 587 (frame width) Height: 342 (frame height) Geometry: 80x24+0+0 So FvwmIdent gives me the frame's size and position and the width/height/position of the client as if the wm had not decorated it (80x24+0+0). Without any options, xwininfo reports the client window's absolute position (+4+22) and the size in pixels (579x316). It can also report the frame's geometry if called with the -frame option (587x342, +0+0). So, what *is* the problem with that? Of course, it _should_ be 80x24+0+0. If you were to then issue a command of: xterm -g 484x316+0+0 That is going to obviously give you one huge XTerm. :) You're looking at the wrong lines of the output. The numbers you are looking for are in the Geometry:-line near the bottom of the window. Aye -- and using those numbers still produce an erroneous size. Huh? For me it says 80x24+0+0, and that's exactly the string I passed to xterm in the first place. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: cross-referenced FVWM documentation
Scott Smedley [EMAIL PROTECTED] writes: Hi all, I have been working on converting the FVWM documentation into DocBook format. You can view some preliminary HTML results on-line. http://members.optusnet.com.au/~scott.fvwm/index.html The most interesting links, so far, are: All Commands Grouped Commands Modules FVWM man page Comments/criticism/feedback most welcome. That looks really nice. Does it still generate a reasonable looking man page. Is the docbook source code much harder to work on that the man page format? Is it possible to start including examples like pictures of windows without totally screwing up the man page generation? -- Dan Espen E-mail: [EMAIL PROTECTED]
Re: CVS griph: * silence compiler warnings
On Sun, Jan 14, 2007 at 03:52:03AM -0600, fvwm-workers wrote: CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: griph 07/01/14 03:52:03 Modified files: . : ChangeLog bin: ChangeLog fvwm-root.c fvwm : add_window.c builtins.c conditional.c events.c externs.h focus.c frame.c fvwm.c fvwm.h geometry.c icons.c menugeometry.c menus.c move_resize.c placement.c session.c style.c libs : FScreen.c FScreen.h Graphics.c PictureImageLoader.c PictureUtils.c PictureUtils.h modules: ChangeLog modules/FvwmBanner: FvwmBanner.c modules/FvwmIconBox: FvwmIconBox.h icons.c modules/FvwmIdent: FvwmIdent.c modules/FvwmRearrange: FvwmRearrange.c modules/FvwmScript: types.h modules/FvwmTaskBar: ButtonArray.c ButtonArray.h modules/FvwmWharf: FvwmWharf.c Wharf.h Log message: * silence compiler warnings Cool, thanks! Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
CVS domivogt: * Properly handle title direction in FvwmIdent.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt07/01/14 09:31:45 Modified files: . : NEWS modules: ChangeLog modules/FvwmIdent: FvwmIdent.c Log message: * Properly handle title direction in FvwmIdent.
CVS griph: * don't loop for ever (may still not work correctly, but at least
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: griph 07/01/14 10:03:02 Modified files: . : ChangeLog NEWS fvwm : icons.c Log message: * don't loop for ever (may still not work correctly, but at least doesn't lock up)
CVS domivogt: * Fixed SmartPlacement; more work on placement infrastructure.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt07/01/14 11:01:50 Modified files: . : ChangeLog fvwm : placement.c Log message: * Fixed SmartPlacement; more work on placement infrastructure.
CVS domivogt: * Icon loop fix.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt07/01/14 11:20:10 Modified files: . : NEWS ChangeLog fvwm : icons.c Log message: * Icon loop fix.
Re: Bug in FvwmIdent's Geometry string.
On 1/14/07, Dominik Vogt [EMAIL PROTECTED] wrote: I don't understand what your problem is. When I start xterm like this: $ xterm -g 80x24+0+0 I get an 80x24 xterm at +0+0. FvwmIdent says: X: 0 (frame x position) Y: 0 (frame y position) Width: 587 (frame width) Height: 342 (frame height) Geometry: 80x24+0+0 So FvwmIdent gives me the frame's size and position and the width/height/position of the client as if the wm had not decorated it (80x24+0+0). Without any options, xwininfo reports the client window's absolute position (+4+22) and the size in pixels (579x316). It can also report the frame's geometry if called with the -frame option (587x342, +0+0). So, what *is* the problem with that? I can confirm Thomas's problem with other windows, namely with Firefox. Strangely enough, for xterm FvwmIdent reports the expected value. Resizing both xterm and firefox windows to the same dimensions: * xterm: Width: 700 Height: 550 Geometry: 116x42+96+66 * firefox Width: 700 Height: 550 Geometry: 699x549+183+120 So it seems that something is wrong.. Unless there's a reason for this to happen. Cheers Renato
Re: CVS domivogt: * Icon loop fix.
On Sun, Jan 14, 2007 at 06:26:47PM +0100, Viktor Griph wrote: On Sun, 14 Jan 2007, FVWM CVS wrote: Log message: * Icon loop fix. What's the difference. ofw isn't used outside the loop anyway. Ah, you're right. I didn't understand your patch correctly. The effect is the same, but the new version is a bit easier to understand (I hope). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: deiconify may loop forever
On Sun, 14 Jan 2007, Dominik Vogt wrote:
On Sun, Jan 14, 2007 at 04:42:23PM +0100, Viktor Griph wrote:
This loop is on line 2288 in icons.c:
for (ofw = NULL; fw != ofw IS_ICONIFIED_BY_PARENT(fw); )
{
t = get_transientfor_fvwmwindow(fw);
if (t != NULL)
{
ofw = fw;
fw = t;
}
}
I'm not sure exactly what it is supposed to do, but if a non-transient
window is iconified by IconifyWindowGroups it will loop forever.
This loop looks for the top window of the transient tree.
Actually, your fix broke that logic because it climbs only one
level up the tree. The right fix is to break the loop if
get_transientfor_fvwmwindow returns NULL. The comparison
(ofw == fw) is there to catch windows that are their own
transients.
My fix did still climb the tree. What it did was to always assign ofw=fw,
and as long as t wasn't null assign fw = t. Which mean that only if t was
the same as fw or t was NULL would ofw == fw, and the loop would end.
It changed the value of ofw after the loop, but it wasn't used anyway.
However I'm still not convinced that this is the right fix. That code was
written without the IconifyWindowGroups option in mind, shouldn't it
really try to climb to the head of the windowgroup as well? Maybe it is
ennoug to use the mark_transient_subtree result. That function doesn't
care about if it's called with the head of a tree or not.
The only effect the loop has is that deiconifying raises, not the window
selected for deiconify, but the root of the transient tree. Isn't it
better to raise the window selected, and let the
styles StackTransientParent and RaisTransient control which windows
actually are raised.
/Viktor
CVS domivogt: * Fixed travelling windows with win_gravity upon restart with ResizeHintOverride style.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt07/01/14 12:12:38 Modified files: . : ChangeLog fvwm : add_window.c Log message: * Fixed travelling windows with win_gravity upon restart with ResizeHintOverride style.
Re: Bug in FvwmIdent's Geometry string.
On Sun, Jan 14, 2007 at 03:54:23PM +, Thomas Adam wrote: On Sun, Jan 14, 2007 at 04:33:56PM +0100, Dominik Vogt wrote: With that, FvwmIdent prints the relevant information to the console. Can you post the output and the (relevant) output of xwininfo please? Sure. I should just point out that I have tried this with FVWM having no config file to load up at all (just in case there was something in my own config file which might cause it). Here's the output from the debug info from FvwmIdent and (selected) xwininfo output: FvwmIdent output: frame 492x340, bw 8, title 16(dir 0), client 484x316 client 484x316, base 0x0, inc 1x1 ^^^ So fvwm thinks the character size is 1x1 (see below). -- units 484x316 xwininfo output: xwininfo: Window id: 0x3cf xterm Absolute upper-left X: 4 Absolute upper-left Y: 20 Relative upper-left X: 0 Relative upper-left Y: 0 Width: 484 Height: 316 Corners: +4+20 -792+20 -792-688 +4-688 -geometry 80x24+0+0 Please note that I don't have ResizeHintOverride set anywhere, although this *does* indeed throw the numbers out, since it reports itself in pixels when I have turned it on. Having spoken to a few people on IRC, they can confirm that FvwmIdent works fine for them, until they set ResizeHintOverride, at which point, the geometry string as reported by FvwmIdent is in pixels. (I consider this to be a bug in itself, but that's a different issue as to why this still isn't working here for me). The reason is that fvwm thinks the character size is 1x1. This happens explicitly with the ResizeHintOverride style (I've committed a patch for that). There are three possible reasons: 1) The user set ResizeHintOverride == Try to set style * !ResizeHintOverride explicitly Note: This style does *not* work if the window is already mapped! 2) The application did not set a character size (or any size hints at all). As xwininfo reports the proper size, this is not the case. 3) The application set an invalid character size (= 0) == look for a message The application window ... has broken size hints (..._inc) on the console. Thanks for your continual assistance on this, Dominik. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CVS domivogt: * Use resize_inc hint even with ResizeHintOverride style.
On Sun, 14 Jan 2007, FVWM CVS wrote: Log message: * Use resize_inc hint even with ResizeHintOverride style. Does this make ResizeHintOverride do nothing? /Viktor
Re: deiconify may loop forever
On Sun, Jan 14, 2007 at 07:01:06PM +0100, Viktor Griph wrote:
On Sun, 14 Jan 2007, Dominik Vogt wrote:
On Sun, Jan 14, 2007 at 04:42:23PM +0100, Viktor Griph wrote:
This loop is on line 2288 in icons.c:
for (ofw = NULL; fw != ofw IS_ICONIFIED_BY_PARENT(fw); )
{
t = get_transientfor_fvwmwindow(fw);
if (t != NULL)
{
ofw = fw;
fw = t;
}
}
I'm not sure exactly what it is supposed to do, but if a non-transient
window is iconified by IconifyWindowGroups it will loop forever.
This loop looks for the top window of the transient tree.
Actually, your fix broke that logic because it climbs only one
level up the tree. The right fix is to break the loop if
get_transientfor_fvwmwindow returns NULL. The comparison
(ofw == fw) is there to catch windows that are their own
transients.
My fix did still climb the tree. What it did was to always assign ofw=fw,
and as long as t wasn't null assign fw = t. Which mean that only if t was
the same as fw or t was NULL would ofw == fw, and the loop would end.
It changed the value of ofw after the loop, but it wasn't used anyway.
Ack.
However I'm still not convinced that this is the right fix. That code was
written without the IconifyWindowGroups option in mind, shouldn't it
really try to climb to the head of the windowgroup as well? Maybe it is
ennoug to use the mark_transient_subtree result. That function doesn't
care about if it's called with the head of a tree or not.
According to the man page, the window group should be iconified
when the group leader is iconified, but *not* if another window of
the group is. So it would be wrong to deiconify the whole group
if just a single window is deiconified.
I don't know if this feature is *usefull* at all, but I don't know
any application that makes use of the window group feature.
The only effect the loop has is that deiconifying raises, not the window
selected for deiconify, but the root of the transient tree. Isn't it
better to raise the window selected, and let the
styles StackTransientParent and RaisTransient control which windows
actually are raised.
I don't know.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
CVS domivogt: * Also override the resize_inc with ResizeHintOverride.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt07/01/14 12:51:18 Modified files: fvwm : add_window.c fvwm.1.in Log message: * Also override the resize_inc with ResizeHintOverride. * Document that FvwmIdent does not show the right geometry with ResizeHintOverride.
Re: CVS domivogt: * Use resize_inc hint even with ResizeHintOverride style.
On Sun, Jan 14, 2007 at 06:29:01PM +, Tavis Ormandy wrote: On Sun, Jan 14, 2007 at 07:19:07PM +0100, Viktor Griph wrote: On Sun, 14 Jan 2007, FVWM CVS wrote: Log message: * Use resize_inc hint even with ResizeHintOverride style. This faq question will have to be updated: http://www.fvwm.org/documentation/faq/#5.16 So this bug has been exploited for years? Ouch. I'll change the man page and revive overriding the resize_inc. Thanks for the hint. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Question regarding ModuleSynchronous man page entry
Hello. Here's the dubious part of the man page entry: This command is intended for use with the (currently hypothetical) module that should be in place before other modules are started. What is this hypothetical module? Cheers Renato
CVS griph: * move common tests to function to avoid code duplication
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: griph 07/01/14 14:57:45 Modified files: . : ChangeLog fvwm : stack.c Log message: * move common tests to function to avoid code duplication * use = 32 character function name
Re: Question regarding ModuleSynchronous man page entry
On Sun, Jan 14, 2007 at 08:06:09PM +, seventh guardian wrote: Hello. Here's the dubious part of the man page entry: This command is intended for use with the (currently hypothetical) module that should be in place before other modules are started. What is this hypothetical module? The former FvwmTheme module (that is now part of the core). I still start it as a module with ModuleSynchronous. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: big do-everything functions or small do-one-thing ones?
On 1/14/07, Dominik Vogt [EMAIL PROTECTED] wrote: On Sun, Jan 14, 2007 at 08:36:31PM +, seventh guardian wrote: Hello I have a question regarding one aspect of the coding: is it better to use big do-everything functions or do-one-thing ones? It's better to use do-one-well-defined-thing-and-do-it-well functions. Personally I try to cling to the Linux kernel coding conventions, and they won't harm fvwm. I explain :) For instance HandleModuleInterface is a big function that, like the name suggests, does everything it may possibly be done with module input: it reads the module input, verifies that there's no error, checks for an expected string if that was asked, enqueue or execute according with the enqueue parameter. One problem with it now is that it requires that the window is read separately (to test for a dead module), otherwise it would require a return parameter to detect this. Other thing, the parameters given to it don't change much. In My_XNextEvent it is always asked to enqueue and not to expect. The other places where it is called is in PositiveWrite (if the module should lock) and in CMD_ModuleSynchronous. These are the places where it does use the expect value, but doesn't enqueue. These last situations are both rare. So what I thought would be better was to have small functions that don't need the current decision logic: one to input, other to execute, another to enqueue and another to test for the expected value. Smaller modular functions are usually better visually and maintenance-wise, but the other important thing is performance. So (for instance) in the most frequent use-case, My_XNextEvent, we would just call the module_receive function and pass its return value to the enqueue function. The question is, does calling two small just-do-it functions bring [much] more overhead than calling only one big conditional function? (I assume we're talking about module input). In comparison to X input, module input is rare (except maybe while moving windows in the pager). Without any testing, I postulate that the amount of I/O is roughly this: I/O type frequencyamount of data - X Inputvery often some small packets X Output sometimessome small to huge packets Module Input rare some small packets Module Output oftentons of smal packets So, the I/O types to optimize are handling input from X and sending output to the modules. If the possible added overhead isn't that important, I would like to eventually apply my (unfinished) local changes to cvs. They make the module code much more modular :-) Hm, did someone mention releaseing 2.5.21? This should be done before (I think the code is ready to be released). I did so, but since I thought I would have time to clean things up I started committing harmless changes. Right now the only issue could be a small lack of cleanliness, which shouldn't affect the compiled result at all. I confess, the code is a bit messy right now.. Should I undo my current patches and do them after the release? Cheers Renato
Re: deiconify may loop forever
On 14Jan2007 19:21, Dominik Vogt [EMAIL PROTECTED] wrote: | I don't know if this feature is *usefull* at all, but I don't know | any application that makes use of the window group feature. I have an app here that acts as though it is a window group. But it might not be - it could just as easily be that the app (which is pretty dodgy) notices deiconification and withdraws its own windows:-( I can readily imagine things like the gimp or other tools-with-floating-widgets being very useful as a window group. -- Cameron Simpson [EMAIL PROTECTED] DoD#743 http://www.cskk.ezoshosting.com/cs/ Without question, the greatest invention in the history of mankind is beer. Oh, I grant you that the wheel was also a fine invention, but the wheel does not go nearly as well with pizza. - Dave Barry
