Re: Grabbing and complex functions
On 29 Jun 2006 18:57:55 +1000, Scott Smedley wrote: Hi Oliver, - Try to grab just 2 times (this is really fast). If the grab succeed everything is ok. If it fails execute the function any way. If you're happy to execute a function even if a grab fails, why go to the trouble of grabbing in the first place? Why not just mark your function NoGrab? Yes, this is reasonable, but a user may decide to mark functions that are fully safe as NoGrab, and functions that may potentially work a bit incorrectly without grab (but he knows it's not critical) as AllowNoGrab. Anyway, such AllowNoGrab is not really needed before 2.6, unlike NoGrab. Regards, Mikhael.
Re: Grabbing and complex functions
On 29 Jun 2006 00:44:22 +0200, Dominik Vogt wrote: I agree that a failed grab can cause lots of problems. Hopefully it's clear that many immediate functions may need the grab too. But I have no idea how to decide if a certain function needs it or not. The only way would be to write a whitelist of commands that are okay to use in a nograb function. We would have to exclude at least: * Anything that can generate dynamic functions because it is impossible to decide about whether a grab is needed (Read, PipeRead, expanding variables or environment variables). We are speaking about a user who knows what these Read and PipeRead commands do. I am not sure why you insist on automatic detection only. * Commands calling or manipulating functions (AddToFunc, DestroyFunc, calling a sub-function). Again, these may be pretty safe, a user should be able to specify NoGrab flag here. * Any command that queries or manipulates the pointer (fvwm freezes if it tries to access the pointer while a grab is active). * Any command that relies on EnterNotify or LeaveNotify events (command may have unpredictable results). * Any command that can not cope with the pointer being moved to a different sceen. * Any command that requires a window to operate on, as the user is asked to select a window if none is selected yet. Currently, 34 commands are of that type (Move, Resize, WindowStyle, Close, Focus, PlaceAgain, ...) * Any other command that may grab the pointer itself (e.g. Exec). The same with Exec (a user knows better). * Conditional commands that use the HasPointer condition. * Maybe all other conditional commands too. * Possibly many more. This ad-hoc blacklist already rules out many - if not most - of the most important commands. I would agree to a nograb patch if it 1) *enforces* proper operation, i.e. refuses to define nograb functions that are potentially unsafe. I don't think a possible problem with NoGrab are that critical. If a user wants to get some nograb-related failures, he should be able to do so. There is no good reason the user has no relable way to do this currently: DefineFunc UpdateTitlePeriodically NoGrab + I PipeRead `printf SetEnv DATE ; date +%Y-%m-%d` + I SendToModule FvwmButtons-Panel ChangeButton ... $[DATE] + I Schedule 2 UpdateTitlePeriodically (And the Schedule time precision is not a problem here.) AND 2) adds useful functionality (doubtful, considering the length of the blacklist above). I believe the automatic detection is too complex and will add more bad than good. The explicit non-default NoGrab flag solves the problem. Also, I took the liberty of adding an AllImmediate function option which allows the condition to be omitted. For example: DefineFunc MyFunc NoGrab AllImmediate + Echo hello + Echo world which I find much more intuitive. The AllImmediate flag indicates that all actions are I - immediately executed. How do others feel about this option? If there are objections I will happily remove it. Well, years ago I suggested to make I specifier optional in functions, because 90% of functions are immediate and there is no confusion if I is omitted. But there was no agreement. I would say that AllImmediate flag is redundant (may be a default). This may be discussed after 2.6.0. Regards, Mikhael.
Re: Grabbing and complex functions
On 29 Jun 2006 00:24:50 +1000, Scott Smedley wrote: Just to clarify ... In my opinion, it's not Schedule that is broken/unreliable. _Any_ function may fail to execute if the pointer is grabbed for ~1 second at the time of execution. It doesn't matter if a function is invoked by Schedule or not - it can still fail to execute in either case. Yes, but the problem of the failed re-Schedule is much more serious, because it is not a one-time failure (whenever the external grab occurs), but an infinite time of failures (non-happened function invocations). Regards, Mikhael.
Re: Grabbing and complex functions
On 26 Jun 2006 13:52:23 +1000, Scott Smedley wrote: DefineFunc would behave much like AddToFunc except for 3 differences: 1. It would generate a warning message if the function already existed. This is bad. Configs should usually be re-read-able. Instead, it should silently apply DestroyFunc. In fact, DefineFunc (combining DestroyFunc and AddToFunc) is something I wanted to have for a long time. It is ok by me to add DefineFunc before 2.6.0, if it fixes issues. Particularly, will it fix reliability of (re-)Schedule? Regards, Mikhael.
Re: CVS domivogt: * New command ModuleListenOnly.
On 24 Jun 2006 06:52:13 -0500, FVWM CVS wrote: Changes by: domivogt06/06/24 06:52:13 Modified files: modules/FvwmPerl: FvwmPerl.1 This man page (like several others) is generated from FvwmPerl.in by make _FvwmPerl.1. Any changes done to FvwmPerl.1 will be lost. Regards, Mikhael.
Re: ModuleListenOnly command
On 24 Jun 2006 13:58:30 +0200, Dominik Vogt wrote: I have just checked in the new command ModuleListenOnly. It works like Module, but fvwm does not send any messages to such a module. I am using it to attach a shell script to the module interface that periodically updates titles of FvwmButtons to display a clock (in the format I prefer, xclock is too stupid) and the process that currently consumes most cpu. I can't say I am very happy about this. Actually, I would not be happy about any new feature added without discussion before 2.6.0. :) The problem with this solution is that in order to use it, every script should include non obvious parts of the module interface, and once the interface is changed such scripts stop to work correctly. AddToFunc InitFunction + I ModuleListenOnly /home/users/bin/fvwm_periodic ... AddToFunc RestartFunction + I ModuleListenOnly /home/users/bin/fvwm_periodic ... I would use StartFunction here, once. But, if I understand correctly, the script does not quit when you quit or restart fvwm (because a pseudo module does not really communicate with fvwm), so you also need to kill it in ExitFunction. I may see several solutions using the existing commands and not having such problems. FvwmCommandS and Exec is one solution that doesn't require the module protocol knowledge. There are several perl-based solutions. We may write a module FvwmButtonsUpdater that gets an FvwmButtons module name (alias) and a list of entries, each is: a button id, its update frequency and a shell command to invoke for title updates (for example, 'date +%T' or 'ps -A --format %C %P %c | sort -n -r | head -1'). Maybe someone will write such configurable module, useful for everybody. It is not very hard after reading fvwm-perllib man. Regards, Mikhael.
Re: CVS domivogt: * New command ModuleListenOnly.
On 24 Jun 2006 16:15:16 +0200, Dominik Vogt wrote: Yes, I changed it in the source when I noticed my mistake but wasn't aware the man page is in CVS. It is generally bad to have generated files in cvs. But just like with our manually generated lex/yacc files in FvwmScript, it is better not to assume every developer has correct perl or lex tools, only those who deal with these languages. For the cvs diff benefits, it is fine to change a spelling error in both .1 and .in files, without regeneration. Regards, Mikhael.
Re: ModuleListenOnly command
On 24 Jun 2006 16:35:21 +0200, Dominik Vogt wrote: On Sat, Jun 24, 2006 at 02:08:43PM +, Mikhael Goikhman wrote: I can't say I am very happy about this. Actually, I would not be happy about any new feature added without discussion before 2.6.0. :) Hm, I don't see that happen in the foreseeable future. Nobody is doing anything in that direction. But is this a reason to make this task harder? The problem with this solution is that in order to use it, every script should include non obvious parts of the module interface, and once the interface is changed such scripts stop to work correctly. Oh, but it doesn't. I don't see how what I said is not true. Unless there is fvwm-shelllib, every user script should include parts of the module interface (like function send), something that even modules in C and perl should not do. And eventually I wasn't able to find out how to do it with FvwmPerl by reading the man page (I'm a zsh-person, not a Perl-person). FvwmPerl is just a specific module for embedding perl into fvwm config, it does not have an easy-to-use support for periodic commands. Of course, options like --periodic-frequency and --periodic-cmd may be easily added. Still, specialized module FvwmButtonsUpdater would be more appropriate. We may write a module FvwmButtonsUpdater that gets an FvwmButtons module name (alias) and a list of entries, each is: a button id, its update frequency and a shell command to invoke for title updates (for example, 'date +%T' or 'ps -A --format %C %P %c | sort -n -r | head -1'). Maybe someone will write such configurable module, useful for everybody. That's the idea. My script should eventually end up with its portability issues fixed (although I don't see how all this could be done without zsh). It is not very hard after reading fvwm-perllib man. fvwm-themes includes FvwmThemesPanelManager module that periodically updates several button titles. It uses Schedule and Deschedule commands. There is also Scheduler tracker that hides all the dealing with these fvwm commands and provides a nice API: fvwm-perllib man FVWM::Tracker::Scheduler If Schedule command is not reliable (I didn't experience this myself), then this tracker may work using internal alarm method as well (someone may possibly improve this method). Regards, Mikhael.
Re: Quoting extended variables
On 04 Jun 2006 11:18:54 +0200, Dominik Vogt wrote: On Sun, Jun 04, 2006 at 12:50:19AM +, Mikhael Goikhman wrote: I think the ultimate solution is explained in file doc/todo-vars. Among other things, it says that we only have variables in format $[], all one letter variables are deprecated, and that a user may request not to quote a value or choose from several quoting styles. However, we should decide about the default behaviour of variables (when no explicit filters are specified). All variables with integer value like $[w.x] or fixed string value like $[version.num] should not be quoted by default. All window name related variables should be qingle-quoted by default. There is no question here, because names are really arbitrary. However, it is not clear about other less-arbitrary strings. I.e. should $. be quoted? Currently it is quoted, but there is almost no chance someone has quote characters in fvwm directories. On the other hand, spaces are a bit more likely, so quoting here has pluses (less to type) and minuses (may be surprised). Should $[w.iconfile] and $[w.miniiconfile] be quoted by default? I don't know. And finally, should $[ENV_VAR] like $[PATH] be quoted by default? Hm. I see pros and cons to do this. Most of variable values (even $PATH) has an expected value, so a user may guess about a proper quoting on his own. On the other hand, the consistent solution would be to always quote any string var. Hm, isn't the right way to fix this mess to rewrite the parser from scratch? I have the impression that we're trying to solve problems that are caused bay the flawed design. Maybe. But I don't think the current parser is very messy, I may understand it. It provides neat functionality and works pretty well. A better design for the parser may certainly be discussed, but I think we may start from something smaller, like variables. We want to have this paradigm regardless of the parser design. Please update file docs/todo-vars if you see improvements to the variable spec. The questions in this message are from the analysis stage. We should understand first, for example, how we want variables to be quoted either by default or in different situations, before starting to redesign. Regards, Mikhael.
Re: Quoting extended variables
On 04 Jun 2006 11:18:54 +0200, Dominik Vogt wrote: On Sun, Jun 04, 2006 at 12:50:19AM +, Mikhael Goikhman wrote: And finally, should $[ENV_VAR] like $[PATH] be quoted by default? Hm. I think I convinced myself that we may continue not to quote it. I see pros and cons to do this. Most of variable values (even $PATH) has an expected value, so a user may guess about a proper quoting on his own. On the other hand, the consistent solution would be to always quote any string var. Hm, isn't the right way to fix this mess to rewrite the parser from scratch? I have the impression that we're trying to solve problems that are caused bay the flawed design. I like the current parser rules, because they are simple and intuitive for me. Of course we may adopt bash (or zsh) command line parsing rules or anything else, but I don't think that some completely new design may somehow solve all problems. It is probably possible to improve parser by adding contexts. I.e. have one rules for Exec processing, other for menu title context, other if we expand inside 'quoted' string, and so on. But still I would leave some control to a user. Let's consider this line: $[command] tail Should the variable be expanded into one word even if it contains spaces? I think, no, because we lose functionality this way. If someone wants one word, he would write: $[command] tail Now, what do we do if the variable contains a double quote? Should it be escaped? Hard question, one answer may be no, because a user may prepare variable to have double quote, space, double quote, specially to overcome this one-word limit. And if he insists, then he may specify: $[command:dquote] tail or (also one-word, but using the single quote, the same effect here): $[command:quote] tail The question of the default filter is difficult. We may decide that: $[command] tail is equivalent either to always-one-word: $[command:in-dquote] tail or alternativelly to potentially-more-than-one-word: $[command:noquote] tail (Unlike dquote filter, in-dquote does not add surrounding double quotes, just escapes them.) All in all, I think we should have all these filters to give the user full control, regardless of the design. This is currently pretty easy to implement. But choosing good defaults may be not easy. Regards, Mikhael.
Re: FVWM: Cancelling 'Pick' command with mouse
On 03 Jun 2006 13:14:11 +0400, Serge (gentoosiast) Koksharov wrote: Key Escape CM NoWindow Pick Destroy This works, but it looks like now impossible to cancel running 'Pick' command using mouse, right? Yes, I know that I can cancel it with 'Escape' button. But I want this keybinding work like real 'xkill' i.e. right mouse button cancels operation. Any ideas? Thanks. You may mouse-click on root to cancel Pick. If there is no root visible, just some sticky panels, then use condition, like: Pick (!CirculateHit) Iconify to be able to click on CirculateSkip windows too to cancel the action. But be aware that currently Pick has a misfeature of passing a click to applications when the condition fails (and this may be bad for pager or gkrellm), so better click on window borders in order to cancel. Regards, Mikhael.
Re: FVWM: automatic placement
On 02 Jun 2006 16:00:19 +, Mikhael Goikhman wrote: PlaceNewWindowAtTheRight XT xterm -name XT +sb This works (it prompts for a window and places a new xterm at the right of it, with gap of 2 pixels). However the next line does not work in the current cvs although it should work too: Next (FvwmConsole) PlaceNewWindowAtTheRight XT xterm -name XT +sb Seems like Pick is broken, it does not reuse the already existing context window correctly and thus variables like $[w.x] are not expanded. Dominik, would you like to fix Pick? So the following minimal example works (it does not currently): AddToFunc testing I Pick Echo $[w.x] Next (FvwmConsole) testing After Restart, I can't reproduce this problem anymore, i.e. $[w.x] is always expanded as expected in all my tests. Previously, it was left as is in the described case. So, the problem is possibly larger and is not trivial to reproduce. If you encounter anything like this, please report. As of now, all code posted in the previous message works as expected. Just a minor note, if you want to paste the whole code into FvwmConsole, then the prefered way to start FvwmPerl is using ModuleSynchronous. Regards, Mikhael.
Re: FVWM: Using WindowShade
On 02 Jun 2006 13:02:47 +0200, stu wrote: + D Current (!Shaded) Style $[w.name] $1 As it was mentioned by Olivier, you would better use WindowStyle here. But regardless of this, you should not quote $[w.name]. The intention is to already properly quote it, i.e. surround with single quotes and prefix all contained single quotes with a backslash (just like deprecated $n). Otherwise any window name that includes double quotes breaks your line. This intention was broken, but I just fixed it in cvs. So in the future, please don't add any additional quotes in lines like: Style $[w.resource] !Title Currently only window name related variables are expanded like this. Regards, Mikhael.
Re: FVWM: how to grow up
On 02 Jun 2006 11:16:39 +0800, pipehappy wrote:
On Thu, Jun 01, 2006 at 04:51:06PM +, Mikhael Goikhman wrote:
FvwmPerl -x
Pick . ResizeMoveMaximize keep %{ $[cw.height] + $[w.y] }%p w 0
When I come across fvwm, I think it can do everything except math.
If it can do it in future, that seems a great feature.
The mentioned function . may do any math (arithmetics, abs, exp, hex,
int, log, rand, sin, sqrt) and string processing (regexps, repetition,
concatenation, split, join, substr, index, sprintf, lc, uc, reverse).
Do you need anything else?
To get help list of functions: man perlfunc, to get help on a function
by its name: perldoc -f cos.
Regards,
Mikhael.
Re: FVWM: automatic placement
On 02 Jun 2006 15:48:14 +0200, Petr Vopalensky wrote: is there any possibility to automatically place a new window next to another already opened window with some space (e.g. 2px) between these two windows? Thanks in advance. There is no way to have user-defined gaps between windows, not that I know about. Regards, Mikhael.
Re: FVWM: automatic placement
On 02 Jun 2006 14:34:31 +, Mikhael Goikhman wrote:
On 02 Jun 2006 15:48:14 +0200, Petr Vopalensky wrote:
is there any possibility to automatically place a new window
next to another already opened window with some space
(e.g. 2px) between these two windows? Thanks in advance.
There is no way to have user-defined gaps between windows, not that
I know about.
On the other hand, if you speak about a specific window those coordinates
are known ($[w.x], $[w.y], $[w.width], $[w.height]), then you may use
the answer from FAQ 3.18 to Move a newly appeared window to a calculated
position. Something like this:
KillModule FvwmPerl
FvwmPerl --export
DestroyFunc PlaceNewWindowAtTheRight
AddToFunc PlaceNewWindowAtTheRight
+ I Pick Eval $a{x} = $[w.x] + $[w.width] + 2
+ I Pick Eval $a{y} = $[w.y]
+ I Exec $1
+ I Wait $0
+ I . Next ($0) Move %{ $a{x}p $a{y}p }%
PlaceNewWindowAtTheRight XT xterm -name XT +sb
This works (it prompts for a window and places a new xterm at the right
of it, with gap of 2 pixels). However the next line does not work in the
current cvs although it should work too:
Next (FvwmConsole) PlaceNewWindowAtTheRight XT xterm -name XT +sb
Seems like Pick is broken, it does not reuse the already existing
context window correctly and thus variables like $[w.x] are not expanded.
Dominik, would you like to fix Pick? So the following minimal example
works (it does not currently):
AddToFunc testing I Pick Echo $[w.x]
Next (FvwmConsole) testing
Regards,
Mikhael.
Re: FVWM: how to grow up
On 30 May 2006 12:53:35 +, pipehappy wrote:
I tried
Maximize 0 growup
And it only can grow up to the upper edge of screen if there is no
other window(Yes, I also find it in man page).
So can anyone give me some tips on how to make the window grow up to
the upper edge of the screen no matter there is a window above it or
not?
It seems you ask for this:
Pick ResizeMoveMaximize keep w+$[w.y]p w 0
Or ResizeMove with the same parameters, depending on what you want.
Accourding to the man page it should work, but the construction w+10p
mentioned in the example does not work for me (no time to check why).
The best I can suggest for now as a replacement for this line is:
FvwmPerl -x
Pick . ResizeMoveMaximize keep %{ $[cw.height] + $[w.y] }%p w 0
Regards,
Mikhael.
Re: Problem on Makefiles
On 28 May 2006 15:20:47 -0300, marcel bertonzzin wrote: Because of the png_LIBS variable, that is set to: -lpng -lz but should be: -L/usr/local/bin -lpng -lz What is the location of libpng.so or/and libpng.a on your system? Do you say that /usr/local/bin? Regards, Mikhael.
Re: Project Support Open Source (SOS) wanted to donation to your project
On 25 May 2006 07:19:33 -0400, Dan Espen wrote: Bob Mutch [EMAIL PROTECTED] writes: Hi Dan, Sent it to the list if that will help and to the top contributors also. Current we are donating $10,000 to 200 projects which is $50 per project. Any opinions on this? I think it is an ok idea. I don't need money right now, and have no much time anyway. But anyone else (Dominik is first) may decide to complete this process (send a PayPal info and add a note on donations.php). Regards, Mikhael.
Re: Incomplete 'Test' command description
On 22 May 2006 00:16:46 +0400, Serge (gentoosiast) Koksharov wrote: I found out that 'Test' command description in fvwm manpage is incomplete. Let me cite an excerpt: Test [(test-conditions)] command snipThey include Version operator x.y.zsnip If it helps, then (or /Version pattern/) may be added here. The Version operator x.y.z test-condition is fulfilled if the logical condition of the expression is true. Valid operator values are: =, , =, , == and !=. That's all about 'Version' operator in the manpage. But little later one example follows: AddToFunc VerifyVersion + I Test (Version 2.5.*) Echo 2.5.x detected + I TestRc (NoMatch) Test (!Version 2.6.*) Echo Future version snip Obviously this example don't fit in 'Test' description in the manpage. I checked and it works anyway. Regards, Mikhael.
Re: FVWM: Windows appearing where they were invoked?
On 16 Apr 2006 11:54:17 +0100, seventh guardian wrote: It doesn't seem to work.. It appears that the current page vars get updated before they are read. Here's what I have: DestroyFunc StartHere AddToFunc StartHere + I Style $1 StartsOnPage $[desk.n] $[page.nx] $[page.ny] + I Exec exec $0 DestroyFunc Browser AddToFunc Browser + I StartHere firefox Firefox It works well for me. If you specify the correct firefox name of course (that is Firefox-bin, not Firefox). Try in FvwmConsole: DestroyFunc StartHere AddToFunc StartHere + I Style $1 SkipMapping, StartsOnPage $[desk.n] $[page.nx] $[page.ny] + I Exec sleep 2; $0 StartHere xterm +sb XTerm StartHere firefox Firefox-bin Regards, Mikhael.
Re: FVWM: Windows appearing where they were invoked?
On 17 Apr 2006 00:45:10 +0100, seventh guardian wrote: There's a minor itch though: it takes me back to the page where it started. Even so, it's better than before! Then you didn't use my implementation of StartHere with SkipMapping: DestroyFunc StartHere AddToFunc StartHere + I Style $1 SkipMapping, StartsOnPage $[desk.n] $[page.nx] $[page.ny] + I Exec sleep 2; $0 StartHere xterm +sb XTerm StartHere firefox Firefox-bin Regards, Mikhael.
Re: FVWM: Windows appearing where they were invoked?
On 17 Apr 2006 00:49:29 +0100, seventh guardian wrote: Oh.. and another one: if the app gets executed from a terminal or from another app, it goes to the same page as before.. not good if you have rox-desktop or any other launching app or desklet.. Maybe if I delete the style afterwards :? I would delete the style after 20 seconds by adding one line: DestroyFunc StartHere AddToFunc StartHere + I Style $1 SkipMapping, StartsOnPage $[desk.n] $[page.nx] $[page.ny] + I Schedule 2 Style $1 !SkipMapping, StartsAnyWhere + I Exec sleep 2; $0 Regards, Mikhael.
Re: FvwmTaskBar fixes, `Pad' documentation fvwm-bug fixes
On 08 Apr 2006 02:02:10 +0400, Serge (gentoosiast) Koksharov wrote: P.S. Question to Mikhael: Why you named one of your kitties `Murzilka'? In USSR we had a children's magazine with exactly such name. It was nice, kind and I read it when I was a kid. Yes, I read it too. And it seems to be fully alive, www.murzilka.org. Regards, Mikhael.
FVWM: Announce: wm-icons-0.4.0 is released
After 5 years of timeout, a new version of Window Manager Icons is out. The main change in this release is addition of 13 new nice icon sets (11 in png format, and 2 in xpm format). All information is available on the home page: http://wm-icons.sourceforge.net/ Since fvwm-themes is fully wm-icons compatible, the fvwm-themes users may update the look of their menus/modules/apps by installing wm-icons-0.4.0 and following short instruction on the home page. Here is an example screenshot: http://wm-icons.sourceforge.net/screenshots/full/migo-20060122.jpg Of course, wm-icons is usable for pure fvwm users too. This version includes 30 icon sets now (84 icons each). No old icon sets were removed, however the plan is to start to remove outdated icon sets. Big thanks go to Mikko Heiskanen (who did most of the work for this release, including the new home page look) and Maciej Szymanski. Regards, Mikhael.
Re: style matching in current CVS
On 06 Apr 2006 12:47:59 +0200, Dominik Vogt wrote: On Thu, Apr 06, 2006 at 12:13:17PM +0200, Viktor Griph wrote: On Thu, 6 Apr 2006, Dominik Vogt wrote: Do you mean this text: They are searched in the reverse order stated. When two conflicting styles apply to the same window, the style that was changed last wins. I think it will help if we use different terms instead of one term style meaning different things. I always use term style option to mean individual bit(s), style to mean named structure, and Style to mean fvwm command. So, how about this: When two opposite style options are specified for the same window (like Sticky and Slippery), then the last specified option wins. Example: Style gnome-terminal SloppyFocus, Slippery Style gnome-* Slippery, SloppyFocus, MouseFocus, HandleWidth 6 Style *-terminal Sticky This results to gnome-terminal to be Sticky and use MouseFocus. In this example, the Style gnome-terminal SloppyFocus, Slippery line is effectivelly optimized out and does not consume memory. Regards, Mikhael.
Re: style matching in current CVS
On 07 Apr 2006 11:42:43 +1000, Cameron Simpson wrote: On 06Apr2006 12:58, mikhael goikhman [EMAIL PROTECTED] wrote: | | When two opposite style options are specified for the same window | (like Sticky and Slippery), then the last specified option wins. Please say opposing instead of opposite. Yes, of course. Regards, Mikhael.
Re: FVWM: add to root menu
On 03 Apr 2006 17:08:35 -0400, Wendell Turner wrote: On Sun, Apr 02, 2006 at 09:11:38PM +, Mikhael Goikhman wrote: On 31 Mar 2006 17:47:16 -0500, Wendell Turner wrote: Is there an easy way to add a custom entry to the beginning of the root menu? The general answer is no, there is no easy way to prepend to menus. Maybe in the future. If you tell us which setup you use, Here are the main elements: fvwm 2.5.15 (from cvs) compiled on Sep 28 2005 at 21:19:57 fvwm-themes-0.7.0-2 from rpm Maybe in the future fvwm-themes will allow to prepend to root menu. then it is possible to try to solve your needs in one or another way. There are several solutions: Read after AddToMenu (reading optional user-or-system-defined file with plus prefixed top menu items); You mean that there are options to the AddToMenu function? No. Read and AddToMenu are both fvwm commands, not functions. Regards, Mikhael.
Re: yet another documentation fixes
On 30 Mar 2006 02:05:18 +0400, Serge (gentoosiast) Koksharov wrote: P.S.1: Where I can find recent mailing list archives? On 'http://www.mail-archive.com/fvwm-workers@fvwm.org/' most recent dated 2005/06/24. The correct url is http://www.mail-archive.com/fvwm-workers@lists.math.uh.edu/ Regards, Mikhael.
Re: FVWM: add to root menu
On 31 Mar 2006 17:47:16 -0500, Wendell Turner wrote: Is there an easy way to add a custom entry to the beginning of the root menu? I see references to main-menu-pre.hook, but it looks like that is a Debian invention, not something in the stock fvwm/fvwm-themes. Would Piperead work for this? I don't really want to change the entire root menu, just add my own at the beginning. Also, it would be nice to do this system-wide, not just to my own account. I've made my own custom rpm with my very own theme in it to accomplish this (which worked ok), but that seemed to cumbersome for just one menu entry. The general answer is no, there is no easy way to prepend to menus. Maybe in the future. If you tell us which setup you use, then it is possible to try to solve your needs in one or another way. There are several solutions: Read after AddToMenu (reading optional user-or-system-defined file with plus prefixed top menu items); calling a function (to be redefined by a user) after AddToMenu; PipeRead with external script to create the whole menu. Regards, Mikhael.
Re: Correction of typo in 'man fvwm'
On 17 Mar 2006 18:34:29 +, Thomas Adam wrote: Just a minor typo that needs fixing. In the main FVWM man page of 2.5.16 on line 8241, there is: Colorset 12 VGradient 200 grey30 gery60 This typo among others was fixed a month ago. Regards, Mikhael.
Re: FVWM: fvwm eat my $TMPDIR
On 13 Mar 2006 01:58:03 +0100, Michelle Konzack wrote: which works up to env perfectly, but if fvwm runs, all variables are there, except $TMPDIR, which mean, mutt, ssh and others refuse to work. fvwm itself does not play with TMPDIR, so it does not eat it. Are you sure you don't set/unset TMPDIR in your fvwmrc or bashrc? Regards, Mikhael.
Re: todo-2.6: E7 - FvwmProxy placement algorithm
On 14 Feb 2006 13:45:10 +, seventh guardian wrote: I found this on the todo-list: E.7 Fix the FvwmProxy placement algorithm (it may loop and can place windows off screen) [dv: added on 02-Mar-2003] I've looked int othe code, but I really don't know what the bug is. Can please anyone point me to where to look, and how to trigger it? Then I cound put my hands on it.. The mail archives are now fully searchable (more or less all years). You may go to http://www.mail-archive.com/fvwm-workers@lists.math.uh.edu/ and type FvwmProxy placement or any other search phrase. Regards, Mikhael.
Re: CVS domivogt: * Committed UnderMousePlacement patch.
On 11 Feb 2006 09:50:34 -0600, FVWM CVS (Dominik) wrote: * Committed UnderMousePlacement patch. Will we apply new patches without any discussion now? :) I think this patch was better (both the name and the functionality): http://www.mail-archive.com/fvwm-workers@hpc.uh.edu/msg05522.html Except that I would use short instead of int in the style struct. And I am not sure whether a window should be forced fully on screen. Regards, Mikhael.
Re: Module.h bug and sugestion
On 10 Feb 2006 08:35:04 +0100, Dominik Vogt wrote: On Fri, Feb 10, 2006 at 01:19:26AM +, seventh guardian wrote: Then we have two options: - Modules don't pass a matching string to fvwm and fvwm is entirely responsible of the module's aliases. - Modules continue to pass the matching string and fvwm translates it if an alias is defined in the core. Hm, would that break the old way FvwmIconMan requested its config liens? I mean *FvwmIconMan*1*foobar ... Instead of the new *FvwmIconMan: 1 foobar ... Or is that completely transparent to the modules? Mikhael? The second line is unfortunately (for backward compatibility with all other modules parsing their config) is sent as: *FvwmIconMan1 foobar ... FvwmIconMan simply supports 2 formats, old with *, and without *. Similarly, FvwmButtons config that looks like: *MyButtons: Frame 5 *MyButtons: (Container) is sent (again, for backward compatibility) as: *MyButtonsFrame 5 *MyButtons(Container) At least DestroyModuleConfig MyButtons: Width and DestroyModuleConfig MyButtons: * do the right thing, i.e. do not affect lines of another alias *MyButtonsFrame: Title my-frame. Of corse, the correct thing is to introduce MX_MODULE_CONFIG packet and new rules (a module may request from the core a config related to the module name, say FvwmScript, or related to its alias, say FvwmButtons, or both, say FvwmForm) and to send the config lines without any prefix. This requires rewrite of all modules and the core. Not before 2.6. Regards, Mikhael.
Re: Module.h bug and sugestion
On 10 Feb 2006 08:25:41 +, Nick Fortune wrote: How about factoring the alias mechanism away from the module alias? You could have a command: AliasModule module-name alias [ alias ... ] This way instead of writing DestroyModuleConfig MonitorPanel: * *MonitorPanel: (1x1, Swallow 'asclock' 'Exec exec asclock') # ... AddToFunc StartFunction + I Module FvwmButtons MonitorPanel You'd write AliasModule FvwmButtons MonitorPanel DestroyModuleConfig MonitorPanel *MonitorPanel: (1x1, Swallow 'asclock' 'Exec exec asclock') # ... AddToFunc StartFunction + I Module MonitorPanel Which seems a little clearer. That way we get to remove the alias from the module arguments, we can deprecate the old usage, and third party modules don't have to use it. For the module side of the operation, I'd pass it in the environment as already suggested. We get a migration path to a cleaner syntax, and we don't have to break anything. This is an option to consider, before redesigning the module interface. However, this syntax will require 2 lines for launching every module, AliasModule and Module, instead of just Module. And we also need UnaliasModule. I.e. now the user should predeclare all module instances he wants to use. I should rething this idea first before agreeing or disagreeing with it. Regards, Mikhael.
Re: todo-2.6: E6 - rename FvwmProxy
On 10 Feb 2006 18:06:55 +, Thomas Adam wrote: On Fri, Feb 10, 2006 at 05:45:21PM +, seventh guardian wrote: Anyway, on that list there's the entry E6, saying FvwmProxy should be renamed. I agree, and suggest FvwmWinTag. I'm indifferent. Proxy makes sense to me in this case -- they're proxy windows that are bound to the current windows on the screen. A name like FvwmWindowLabels or FvwmProxyWindows makes even more sense. Please everyone who cares vote: http://fvwm.lair.be/viewtopic.php?t=1202 Regards, Mikhael.
Re: Adding a Shift command
On 10 Feb 2006 23:34:15 +0100, Viktor Griph wrote: Seeing that there has only been one new command in the last 2.5 years I think it was time to add another. ;) No, it means it is a time to spend all energy on releasing 2.6. :) Then any number of new commands and new features may be added. I think that a parameter shifting command for use in functions could be useful. It could be used for small recursive (yes I know, that would not be very efficient) function calls: AddToFunc Inline + I $0 + I Shift + I Inline $* A sample call of the above would be Function Inline WindowStyle !Title, !Borders, !Handles UpdateStyles \ Maximize 100 100 Break Appart from that it would also provide meanns to get direct access to positional paramiters after $9. Thoughts? Is this something that anyone but me would use? There is a problem with variables looking like $X on the command line. I don't know whether we should absolete $0 .. $9 and $. plus $*. Maybe not. But at least, as the first step we may start to support $[0], $[12]. As well as $[2-5] (four arguments starting from the third, space separated). This, together with the filter/quoting suggestion for all variables http://www.mail-archive.com/fvwm-workers@hpc.uh.edu/msg05721.html should make your Shift command redundant. Regards, Mikhael.
Re: EdgeScroll and pixel steps
On 11 Feb 2006 00:50:13 +0100, Viktor Griph wrote: Currently EdgeScroll divides pixel steps1000 by 1000 and enables wrap. I belive this to be a bug (and is reportd as sush (#3162)). However, it is useful to allow for warps when using pixel steps as well, so just removing that ability is no good solution. One possible solution would be to add another way of specifying wraps to the syntax, and make it the required method for pixel sizes (or change the check with pixels so that the size has to be larger than the screen width, and an even multiplicand of 1000, in order for division to take place (for compability with configs using for example EdgeScroll 1024000p 768000p)). I think the intention was to only divide the percentage values by 1000 (the ones without p suffix). This is also what the man page says. So, EdgeScroll 1024p 768p should be fixed not to wrap. I can think of several possible syntaxes, and can't decide on which one is best. One can either add a prefix (or another suffix) option 'w' to the individual coordinates. (w1024p or (1024pw or 1024wp)), or one can add optional keywords to the EdgeScroll syntax after the step parameters. (i.e. EdgeScroll 1024p 768p wrap|wrapx|wrapy) The last option seems better to me, although I don't think this is really needed, anyone may achieve this now if he specifies 100% or 50%. Regards, Mikhael.
On module names and aliases
On 10 Feb 2006 16:48:49 +, Mikhael Goikhman wrote: On 10 Feb 2006 08:25:41 +, Nick Fortune wrote: You'd write AliasModule FvwmButtons MonitorPanel DestroyModuleConfig MonitorPanel *MonitorPanel: (1x1, Swallow 'asclock' 'Exec exec asclock') # ... AddToFunc StartFunction + I Module MonitorPanel This is an option to consider, before redesigning the module interface. However, this syntax will require 2 lines for launching every module, AliasModule and Module, instead of just Module. And we also need UnaliasModule. I.e. now the user should predeclare all module instances he wants to use. I should rething this idea first before agreeing or disagreeing with it. Another serious problem with this suggestion is that now we start to manipulate with strings like ColourTable or MonitorPanel and have no any idea whether they are actually FvwmButtons, FvwmForm, FvwmScript, FvwmGtk or maybe even FvwmEvent. And these are very different modules with different configuration syntaxes and command line options. Several years ago I had and still have the following idea in mind, that seems to solve all problems. However it applies a restriction on the module alias name. And this is its only drawback. The alias name (or more correctly the module id) is anything that is modulename-subname. I.e. FvwmScript-ClockMonitor or FvwmForm-Talk. Now, a module should receive subname and not alias as we know it. Then this module id is used everywhere straightforwardly: Module FvwmButtons-Monitor -g 240x360 KillModule FvwmButtons-Monitor SendToModule FvwmButtons-Monitor PressButton 2 *FvwmButtons-Monitor: Colorset 1 I think, this syntax is pretty clean and self-descriptive. If a module does not accept multiple instances, then it may still be accessible as FvwmBanner (with no subname needed). The FvwmForm and FvwmScript configurations shipped with fvwm already follow this naming scheme. As well as all modules in fvwm-themes. I currently don't see a better solution for module ids. Regards, Mikhael.
Re: Module.h bug and sugestion
On 09 Feb 2006 22:24:44 +0100, Dominik Vogt wrote: Hm, what about passing the module alias as an environment variable? It's ugly, but we're already doing it with FVWM_VISUALID and FVWM_COLORMAP. An FVWM_MODULE_ALIAS wouldn't do further harm. However, this doesn't solve the syntax issue on the fvwm side. What can we do about invocations like FvwmButtons ColourTable (right from my config file)? Well, one of the option is to add a new command, ModuleAlias ColourTable FvwmButtons [usual args without alias] and pass an alias to modules (preferably in non-user arguments, and not using environment variable). Another option is to implement a powerful option parser, like it is done in perllib, and have a C equivalent of declaration of all options in the module, like: -c|--color = string, -q|--quiet = none, the first non-option argument may be considered alias, like it is done now, but more accurately. This all may be done more or less transparently in the module library, because the module should supply the option spec, and then the alias name is sent back to the core. And the third option is not to change anything before 2.6.0. The heuristics works pretty well for the cases where aliases are used. I don't see any good reason to start to rework all modules now, risking to lose compatibility and insert new bugs, when we are in the freeze. Class (6) modules are broken at the moment, i.e. it's not possible to kill them with KillModule Modulename because their argument is interpreted as an alias name. FvwmScript is not really broken. It is intended that the parameter works like an alias, although there is no separate config for such aliases. In any case, modules invoked as Module FvwmScript MyConfig may be killed using KillModule FvwmScript MyConfig, even if MyConfig is a full file path, but usually it is something like FvwmScript-WidgetDemo. Perl have the alias name at the end of their option Well, the alias may as well come before the options or in the middle, in any perl-based modules that ask for EnableAlias and EnableOptions. And, as I said previously, the alias name does not conflict with the options, because the options may be automatically parsed accourdingly to the spec _anywhere_ on the command line and then are removed from the arguments. I say this not to suggest that the alias _should_ be allowed to come before or in the middle of the options, but that it is not a problem for a proper option parser, configured to treat all - words specially. Any ideas for a clean interface that breaks only configs that are really weird? The module interface should be redesigned. Together with the module syntaxes. We may do it cleanly in 2.7 or 2.9 versions. The compatibility may be slightly broken then. I strongly prefer, however, to release 2.6 first, before any changes in the module interface. Regards, Mikhael.
Re: Module.h bug and sugestion
On 10 Feb 2006 01:19:26 +, seventh guardian wrote: For instance (using your example syntax): 1 - We call Module FvwmPager --alias foobar 2 - FvwmPager will name itself FvwmPager and would request the *FvwmPager lines. 3 - fvwm knows that this instance of FvwmPager is aliased as foobar and would search for the *foobar lines. 4 - fvwm then sends the *foobar lines to the module, but translated to *FvwmPager. Such workflow would be too overcomplicated. In the ideal world it may be: * a module requests its static config * the core sends corresponding Timeout 5 sec, Colorset 10 lines The dynamic config is sent similarly, if a module requests this. Regards, Mikhael.
Re: Simulate button press in FvwmButtons
On 08 Feb 2006 18:36:58 +0300, George Nephrite Potapov wrote:
On Wed, Feb 08, 2006 at 04:01:15PM +0100, Dominik Vogt wrote:
Here is the correct one. I'm very very sorry.
Thats a nice patch with an important feature.
I agree.
Now, I have massive changes locally that make indentation of several
FvwmButtons files consistent with the main fvwm code. It will conflict
with this patch, but fixing this patch is much easier than my changes.
Can you please submit a patch after I commit the first pass on
FvwmButtons indentation changes?
I also have a request to you. Your patch looks like:
+void ButtonPressProcess (b, act)
+button_info *b;
+char **act;
+{
+ FlocaleNameString tmp;
+int i,i2;
+
+memset(tmp, 0, sizeof(tmp));
+ if (b !*act b-flags.b_Panel)
+ {
+ ActiveButton = b;
I.e. in one small piece of code you use four variations for indentation:
* 2 spaces
* 4 spaces
* 8 spaces
* 1 tab
Please, correct your patch (after my commit) to consistently use 1 tab
only for indentation. Also, using other KR conventions, like a space
after a comma or a space after non-functions (if, while) would be nice,
to be consistent with the main fvwm code. Thank you.
Regards,
Mikhael.
Re: FVWM: Synchronisation problem with FvwmRearrange?
On 08 Feb 2006 14:52:29 +0100, David Vilar wrote: I have a problem with FvwmRearrange. I have two functions like this (in a simplified form): DestroyFunc Expose AddToFunc Expose + I ModuleSynchronous FvwmRearrange -tile -maximize -m -mn 3 + I NoWindow Pick DeExpose [w.id] DestroyFunc DeExpose AddToFunc DeExpose + I All (CurrentPage, !Iconic, CirculateHit, !Sticky) Maximize Off + I WindowId $0 WarpToWindow 50 50 The goal is to show an overview of all the windows (inspired by the expose of MacOS), and then to be able to select a window, which will get focus, and the rest of the windows go back to their initial sizes and positions. The problem I have is that the NoWindow Pick DeExpose... line gets executed before the windows get reorganized by FvwmRearrange, even though I use the ModuleSynchronous command. Is this a bug in FvwmRearrange or am I doing something wrong? A module should implement an intended synchronization (if applicable) for ModuleSynchronous to have any effect. Some modules work asynchronously by default even if you invoke them using ModuleSynchronous, and require an option (like: FvwmM4 -lock), some other modules work synchronously with ModuleSynchronous and have an opposite option (FvwmPerl --nolock). You may add support for synchronization in FvwmRearrange if you need it. Regards, Mikhael.
Re: FVWM: tearoff menu move
On 09 Feb 2006 01:10:43 +0100, Daniel Vrcic wrote: I have some entries in my FvwmRootMenu which allow me to browse through my $HOME dir. I've found that pretty useful especially using TearOff menu thing. Launching commands on certain files in certain subdirectories are just one click away. Neat. :) But, I'm often in situation where I need to have several submenus TearOffed from root menu and placed somewhere else on the current page. I would like to do that manually by dragging each of them on position where I want. Is that possible somehow? Do you mean this: Style fvwm_menu ManualPlacement Or you ask how to bind a Move dragging to window decorations? Regards, Mikhael.
Re: FVWM: is there a way besides recapture....
On 08 Feb 2006 20:54:26 -0500, Peter Williams wrote: According to FvwmDebug, there are no configure_window messages posted to the modules that FvwmPager could latch on to in order to detect when a window backcolor changes. The only messages sent to the modules in my case (restyling as a result of a window name change) are m_visible_name, m_icon_name, and m_window_name. FvwmPager could check for backcolor when it receives one of those but that seems kind of silly... alternatively fvwm could brodcast an m_configure_window message to the modules whenever a window style changes. Does that sound reasonable? Theoretically this is correct (every change in M_CONFIGURE_WINDOW values should be reported in one or another way). Practically this will make this packet even more floody. M_CONFIGURE_WINDOW and M_FOCUS_CHANGE should be redesigned. I am not sure sending fore_color and back_color to the modules is a good idea. I would send a window colorset number instead. The colorsets are the way to go, some pager options (like Window3DBorders) only work with colorsets. I think the correct things to do in the future is to alter the content of M_CONFIGURE_WINDOW as I described, send it on every Style Colorset, and alter the pager to support colorsets per window (i.e. use the colorset number sent in the packet, unless global WindowColorsets is defined). I see no good reason to support Style BackColor, since it is scheduled to be removed in the future. Colorsets should be used instead. Regards, Mikhael.
Re: Patch: FvwmAnimate using ParseModuleArgs() - NOT WORKING YET
On 04 Feb 2006 16:56:47 +, seventh guardian wrote: existing structure only stores the name, and not the asterisk. Of course we could use the existing char* MyName, but that would defeat the whole purpose of using the ModuleArgs struct. I wonder if we need the asterisk in the first place. Wouldn't it be easyer new-code-wise to use only the name for pattern matching? It could be stripped off by fvwm or simply not used in the config files. (since this is only experimental code we are allowed to forget backward compatibility issues) Eventually you have to deal with compatibility. Yes, but unless there's a reason for the use of the asterisk, it is cleaner not to have it. Configuration keywords are changing all the time, it won't be that difficult to strip the * from the config files. Here you speak about the fvwm configuration. You can't omit the asterisk without inventing a new syntax that does not conflict with the syntax of fvwm commands and functions. I see no problem in the asterisks syntax, it seems to be more optimal than other possible syntaxes for module configs. By the way, anyone knows why is the asterisk there for? Here I suppose you ask about the asterisk sent in M_CONFIG_INFO packets. I suggest you to learn the fvwm-to-module protocol more in depth. You may run FvwmGtkDebug or FvwmDebug to see what is sent by fvwm to a module on its Send_ConfigInfo request. You may discover that the asterisk is needed to distinguish from other M_CONFIG_INFO packets that carry a non module configuration. BTW, perllib solves this by having two tracker types, GlobalConfig and ModuleConfig, so a module in perl has a nice API. Redesigning the module protocol may be fine in the future, but this would mean much larger changes than you think. A good suggestion may be, for example, to add a new module packet MX_MODULE_CONFIG carrying the configuration line without the leading *FvwmModule: , and not just omitting an asterisk, as you suggest. Please do not break any compatibility right now. Let's not forget, we are in the freeze before 2.6.0. Regards, Mikhael.
Re: Patch: FvwmAnimate using ParseModuleArgs() - NOT WORKING YET
On 04 Feb 2006 19:42:58 +, seventh guardian wrote: Yes, but as I found in the source code, modules distinguish them by looking for the *FvwmMyname string instead of just the asterisk. I don't know about perl, but c modules usually do that. In this case it would be as easy to look for just for FvwmMyname, without needing either the asterisked string or calling CatString3. As I said, a module gets M_CONFIG_INFO packets from fvwm, with text like: DesktopSize ... ImagePath ... Colorset ... *FvwmAnimate... You may add a higher level API similar to what perllib does (to work with GlobalConfig, ModuleConfig, Colorsets), but you can't just omit an asterisk when you send or match the text, because a user may have a module with any name. Regards, Mikhael.
Re: Module Alias standard and FvwmButtons
On 04 Feb 2006 22:49:00 +, seventh guardian wrote: I'm changing the official modules to use the new ParseModuleArgs function, and I have a question regarding the module Alias argument. Is it in fact a protocol standard or is it something some modules use? This is not currently the standard. Each module deals with this on its own, because they all have their own syntaxes. Moreover, fvwm itself has a heuristic to try and extract an alias from the module invocation line (to be used in SendModule and others). This does not work in 100% of cases. For this to work in all cases, the alias should be explicitly visible in the syntax (using some convention or a special ModuleAlias command, the details are not important now), and the module protocol should have explicit support for aliases. I say that because some modules do use the argv[6] as an alias, but others get the name by other means from the args. Like FvwmButtons, which assumes the first unmarked argument as an alias. This is not necessarilly argv[6]. So the question is, do we want a real protocol extension for this or just a common thing. It makes no sense to use ParseModuleArgs unless it does simplify the module. I can change FvwmButtons to use argv[6] as an alias right now. But there would need to be an updating of the manual, and maybe lots of people would need to change their configs.. No, users should not be required to change their configs any time soon. Can we please suspend this discussion until 2.9 (pre 3.0) branch is open. I have a lot to say on this topic. But this is really not the time to redesign the module protocol. I may also suggest to suspend your ParseModuleArgs work because of this, as you say yourself. There are old fvwm-workers threads discussing the issue (including module aliases), but I don't have urls to these discussions right now. If you want some reading on automatical parsing of module args and the alias, run fvwm-perllib man FVWM::Module and read about new constructor, including its parameters EnableAlias and EnableOptions. Regards, Mikhael.
Re: FVWM: fvwm compile error running findcmd.pl
On 02 Feb 2006 11:07:54 -0500, Jeff Gardner (jtg) wrote:
Can you tell me what's causing this while running make install from
fvwm?
if test -n /router/bin/perl -a -x /router/bin/perl; then \
/router/bin/perl ./findcmd.pl /users/jtg/bin -sh \
../../fvwm/functions.c FvwmCommand.sh; \ else echo '# Did not
find perl during FVWM install' FvwmCommand.sh; fi
syntax error in file ./findcmd.pl at line 32, next 2 tokens my(
What is the output of:
/router/bin/perl -MConfig -le 'print $Config{version}'
I may only guess that your perl version is so old (10 years old?) that it
can't be used here.
This is a very old stuff (findcmd.pl building FvwmCommand.pm).
Theoretically FvwmCommand.pm may be usable for users wishing to control
fvwm remotely from perl, but this script is broken anyway, there is now
a different mechanism to get the list of all fvwm commands.
Mean time, try either echo '' modules/FvwmCommand/findcmd.pl or
env PERL=/bin/true ./configure to solve your problem.
Regards,
Mikhael.
Re: FVWM: fvwm compile error running findcmd.pl
On 02 Feb 2006 21:12:00 -0500, Jeff Gardner (jtg) wrote:
fume:/users/jtg/.fvwm% /router/bin/perl -MConfig -le 'print $Config{version}'
Unrecognized switch: -MConfig.
Well, if you have perl 4 or 3 in your PATH... FVWM did not exist yet
in 1990. :)
In any case, as I said earlier, generation of FvwmCommand.sh and
FvwmCommand.pm should be fixed. Either these files should be removed
completely, or statically generated by perllib/FVWM/create-commands
script (together with statically generated perllib/FVWM/Commands.pm
and docs/COMMANDS).
Does anyone use FvwmCommand.sh or FvwmCommand.pm? I guess no, since they
are auto-generated empty in 2.5.x and noone complained yet.
Regards,
Mikhael.
Re: FVWM: How to get a application's focus auto call by gmrun.
On 19 Jan 2006 11:32:37 +0100, Michelle Konzack wrote: Am 2006-01-12 16:00:02, schrieb Mikhael Goikhman: Style gmrun GrabFocus I use it to (on grun) but because the maus pointer does not move, it is very iritating. Ist there a possibility to move the mouse pointer to? It would be more iritating for me to move the pointer without asking me. But you may read FAQ #3.18, as posted in this thread, and use a wrapper function to start grun, then WarpToWindow to it. This way you decide whether to move the pointer to the bottom window part or its center. Regards, Mikhael.
Re: make rpm-dist and deb-dist both fail with the same error
On 18 Jan 2006 12:45:21 +0100, Dominik Vogt wrote: On Sun, Jan 15, 2006 at 09:44:49PM +, Mikhael Goikhman wrote: Just tested. Mere make is broken on the released fvwm-2.5.15 tarballs. Hrmpf, why didn't make distcheck catch this? No matter how smart make distcheck is, it is always possible to fool it so that make in the subtree created by make dist works, but make in the same dist tree outside of the source tree fail. This was the case, a new Makefile.am code specifically used the files from the outer tree. Regards, Mikhael.
Re: Patch: HasTitle and HasBorders
On 18 Jan 2006 18:53:58 +, Thomas Adam wrote: I'd been meaning to send these in for a while, but University work always seems to get in the way. :) I've created two patches[1] --- very minor ones that add two new conditionals: HasTitle -- Checks to see whether a window has a titlebar or not. HasBorders -- Checks to see whether a window has a border or not. I am all for adding these conditions, but implementation is incorect. HasBorders can't work, since you do not use any window info for it. Hint: you may use has_no_borders window flag for this. Do you want to submit a correct patch (with all documentation too)? Regards, Mikhael.
Re: Patch: HasTitle and HasBorders
On 19 Jan 2006 01:16:28 +, Thomas Adam wrote: On Thu, Jan 19, 2006 at 12:57:18AM +, Mikhael Goikhman wrote: I am all for adding these conditions, but implementation is incorect . HasBorders can't work, since you do not use any window info for it . Hint: you may use has_no_borders window flag for this. Ah. But I did add a flag to fvwm.h for this: has_borders. I would have used has_no_borders, and I probably should. I'll change it, if you like? You added a flag that noone sets (it is always zero). Another side effect after applying your patch is Move becomes Outline instead of Opaque after Restart --dont-preserve-state. Please test the patches thoroughly. Regards, Mikhael.
Re: Patch: HasTitle and HasBorders
On 19 Jan 2006 01:16:28 +, Thomas Adam wrote: OK. I'll do this in the morning, after I have slept. We are not really in hurry. In fact, I would feel more comfortably before applying any patch if its author tells that he runs fvwm with this patch applied for several days without problems and that he verified all new (and some old) functionality in variety of ways. Thanks for contributing. Regards, Mikhael.
Re: FVWM: icons sizes
On 17 Jan 2006 10:33:23 +0100, [EMAIL PROTECTED] wrote: On Wed, 11 Jan 2006, Dominik Vogt wrote: The only way to get full titles at the moment is to disable icon images: style * icon, iconoverride (and delete all other icons specifications from the config file). thank you for this information I tried it, and it works fine for xterms windows (it actually gives as icon the reduced image of the original window, which is more informative than the picture of a terminal...). It doesn't work for some other programs (gvim, elvis) which have built-in icons, but it seems that there is nothing to do, except trying to disable the icon at the program call. Unfortunately, there is no currently way (no, that I know of) to disable all client-specified icons. Style * IconOverride only works for windows that match some non * Icon definition. There is no currently way to cause them to use the default Style * Icon icon instead. So, unlike what Dominik said, Style * IconOverride does not affect such windows. You should explicitelly define Icon for each problematic window to make IconOverride have any affect at all. Style Gvim Icon norm/editor.xpm (I suppose, in your specific case it would be very wide empty.xpm, or so, but I speak about the general case where icons are visible.) I should add that I never liked such (useless IMHO) IconOverride logic. Regards, Mikhael.
Fixed 2.5.15 tarballs are in place
For the record, the fixed tarballs are in place. If one happens to get the old 2.5.15 tarball, he may just remove the FvwmTabs.1 rule from the end of modules/FvwmTabs/Makefile[.in]. Regards, Mikhael.
Re: make rpm-dist and deb-dist both fail with the same error
Just tested. Mere make is broken on the released fvwm-2.5.15 tarballs. I don't think we should release new version. We should do this: * unpack tarball, fix one Makefile.am by adding one character, pack it * move cvs tag version-2_5_15 on 2 files (Makefile.am, FvwmTabs.1) I will do this and upload fixed tarballs, then Jason just replaces them. Meantime, Jason, please remove fvwm-2.5.15.tar.gz and bz2 from ftp. Regards, Mikhael.
Re: make rpm-dist and deb-dist both fail with the same error
On 15 Jan 2006 21:44:49 +, Mikhael Goikhman wrote: Just tested. Mere make is broken on the released fvwm-2.5.15 tarballs. I don't think we should release new version. We should do this: * unpack tarball, fix one Makefile.am by adding one character, pack it For the record, I applied the same trivial fix to modules/FvwmTabs/Makefile.in and replaced FvwmTabs.1 to be consistent with the cvs tag. I tested make rpm-dist and it worked well. * move cvs tag version-2_5_15 on 2 files (Makefile.am, FvwmTabs.1) I will do this and upload fixed tarballs, then Jason just replaces them. I can't upload, since it seems that the old tarballs are still not removed from incoming/ (I sent a private request 30 minutes ago). Until this is resolved, the fixed tarballs are uploaded to: http://fvwm.sourceforge.net/releases/ Regards, Mikhael.
Re: FVWM: How to get a application's focus auto call by gmrun.
On 13 Jan 2006 00:29:52 +0800, Joey Watson wrote: thanks for you answer my question. I am not familiar with fvwm config file grammar. but I think maybe you misunderstand what I mean. I mean that I want automatically set focus to the application what called by gmrun. Style gmrun GrabFocus seems make gmrun get focus. You may either always pass a focus to any new window: Style * GrabFocus, or implement the solution from FAQ #3.18. http://fvwm.org/documentation/faq/#3.18 Regards, Mikhael.
Re: FVWM: Problem with SnapAttraction
On 12 Jan 2006 10:59:23 -0500, Emilie Ann Phillips wrote: Snap attraction is disabled by holding alt during a move. Is there a way to disable this? This behaviour is disabled unless you intentionally release Alt and press it again. If you run an fvwm version with a bug, please upgrade. Regards, Mikhael.
Re: FVWM: GrabFocusOff
On 10 Jan 2006 23:03:07 -0500, Nathaniel H. Stickney wrote: 1) Style * GrabFocusOff does not seem to prevent Gaim from grabbing focus, unsure about other applications. I have tried just GrabFocusOff and also Style * GrabFocusOff to no avail. I can't reproduce this with Gaim 1.3.1. What is exactly the problem? !GrabFocus is the default, so Style * GrabFocusOff will not normally change things. You would possibly need Style Gaim !GrabFocusTransient, but gaim does not use transient windows (my version at least). Do you mean the Raise window on events option in Preferences, or maybe auto-raising/focusing the chat window when double clicking a buddy item? To prevent the last one, use Style Gaim !FPFocusByFunction in 2.5.x. 2) Using fvwm-menu-directory, my menus open the first level of the directory, but will not pop up the subdirectories. How can I fix this problem? Again, what is exactly the problem and the syntax you use? You may take a look at fvwm-themes, the root menu has System submenu with 4 menu items that call fvwm-menu-directory: Browser# opens separate Menu Browser (cached) # opens separate Menu Root dir # opens Popup Home dir # opens Popup This is all described in man fvwm-menu-directory. Regards, Mikhael.
Re: CVS migo: it works well with automake/aclocal-1.4 and 1.5, 1.6, so do not require 1.8
On 09 Jan 2006 00:25:46 +0100, Dominik Vogt wrote: Actually, requiring 1.8 was an accident. I wanted to upgrade to 1.6. Of course the current code works with 1.4 becuase I did not change anything essential, but in the future I'd like to have the new macros. Both automake 1.4-p6 and 1.6.3 (two versions I have on my home machine) were released on 2002-07-28. I may test future changes against 1.4. Regards, Mikhael.
Re: FAQ Update: Style lines.
On 06 Dec 2005 13:07:46 +, Thomas Adam wrote: Something that I have been seeing a lot recently, is the question of Style lines, how they're applied, and what things can go wrong. This is more so observed in #fvwm on irc.freenode.net, although I see it a lot on the FVWM Forums. How about the forum site changing title of the pages to FVWM spelling? This would at least eliminate problems for people having occational Style Fvwm* line (meaning to match modules, not browsers). Regards, Mikhael.
Re: FVWM: How to center windows ? :-/
On 30 Nov 2005 16:07:19 +0100, Michelle Konzack wrote: Am 2005-11-25 13:44:22, schrieb Mikhael Goikhman: Just a random note. Since you set FVWM_USERDIR, you may just call fvwm without parameters in all 3 cases above. But it does not like to read the config only the fvwm2rc. It was the reason for -F. I can't reproduce what you say. If CenterPlacement worked for you, then you run 2.5.11+ and ~/.fvwm/config should be honored. Anyway, my point was you may have a single fvwm call after condition; with or without -f. Style Xdialog UsePPosition Style xmessage UsePPosition Aha... A second option? I am not sure I understand the question. You asked why Xdialog -center or xmessage -center didn't work with your config. I explained why. In any way, I am glad you solved the problem. Regards, Mikhael.
Re: TrianglesUseFore patch.
On 14 Nov 2005 01:31:05 +, Malcolm Still wrote: This patch allows users to use their menu foreground colour for submenu triangles, by using the new MenuStyle keyword TrianglesUseFore, e.g.: MenuStyle * TrianglesSolid, TrianglesUseFore I've uploaded the patch to my webspace at: http://rv.sdf-eu.org/trianglesusefore.diff I think this patch is short and good. Can you also patch all other relevant files, like the man page, NEWS? Regards, Mikhael.
Re: FVWM: [frie...@nomaden.org: Style Fvwm* (and others) in default theme]
On 13 Nov 2005 14:10:45 +0100, Friedrich Delgado Friedrichs wrote: I tried to send the following mail to the fvwm-themes list a while ago, but I failed to notice that it is a subscription-only list. I suggest that the documentation of fvwm-themes be updated to include a non-subscription bugreport address. You may use a SF bugtracker or this list if you don't want to subscribe. Date: Tue, 1 Nov 2005 21:56:21 +0100 To: [EMAIL PROTECTED] Subject: Style Fvwm* (and others) in default theme I still use the style of the default theme and I wondered why my firefox window got sticky all the time when I looked at the fvwm forums on http://fvwm.lair.be/. Then I noticed the following line in /usr/share/fvwm/themes/default/styles: Style Fvwm* Sticky, Title, Handles, WindowListHit, CirculateSkip It's probably not such a good idea to set something like this in the default theme :c) Agree. This line causes confusion and will be removed. Regards, Mikhael.
Re: FVWM: Colorsets (hi sh) problem
On 05 Nov 2005 04:13:35 +0100, [EMAIL PROTECTED] wrote: On Sat, 5 Nov 2005 02:26:54 + Mikhael Goikhman [EMAIL PROTECTED] wrote: Please try to create minimal-config file to be used as in fvwm -f minimal-config that reproduces your problem. Thanks for the tip, but unfortunatelly I can reproduce it even with a minimal configuration file. For example this one, that essentially is a background picture, and the two panels along with the colorsets that they use: I can reproduce the problem with your config. Even if Exec fvwm-root is replaced with PipeRead `fvwm-root`. The problem goes away if to prefix the Colorset 10 line with Schedule 3000, but this is not the real solution, of course. Hopefully someone will take a look at the colorset code. Regards, Mikhael.
Re: FVWM: Colorsets (hi sh) problem
On 05 Nov 2005 13:21:39 +, Mikhael Goikhman wrote: On 05 Nov 2005 04:13:35 +0100, [EMAIL PROTECTED] wrote: Thanks for the tip, but unfortunatelly I can reproduce it even with a minimal configuration file. For example this one, that essentially is a background picture, and the two panels along with the colorsets that they use: I can reproduce the problem with your config. Even if Exec fvwm-root is replaced with PipeRead `fvwm-root`. The problem goes away if to prefix the Colorset 10 line with Schedule 3000, but this is not the real solution, of course. FYI, the problem also goes away if you replace Exec with PipeRead and prefix the Colorset 10 line with AddToFunc StartFunction I. So, maybe you should use this as the current workaround. Regards, Mikhael.
Re: FVWM: Colorsets (hi sh) problem
On 05 Nov 2005 02:05:35 +0100, [EMAIL PROTECTED] wrote: The problem is that the colorsets seems to not completely apply in this case at startup, and I dont know the reason. I have defined a FvwmButtons instance with Frame 1, the colorsets are made in a way that hi=sh, so, even having a frame, they seems flat, because the two colors of the frame are the same, and it just seem a plain line. It works, but works only when I restart the wm. I created a config file that contains all info you provided, i.e. one Colorset 10 line, *FvwmTaskbar lines, and FvwmButtons FvwmTaskbar. I see no problem with sh hi colors of the corresponding rectangle. Please try to create minimal-config file to be used as in fvwm -f minimal-config that reproduces your problem. Regards, Mikhael.
Re: FvwmTabs module
On 03 Nov 2005 16:03:56 +1100, Scott Smedley wrote: A while back there was some talk about including the FvwmTabs module as part of the Fvwm distribution. Are people still happy for this to happen? You should include it. It is fully ready for this. Regards, Mikhael.
Re: FvwmTabs module
Just to clarify. By ready I didn't mean the functionality (this is something users should decide about), but the fact it is written properly. So that even it requires some external things (tk and more), these are not required in installation time, and the module is still runnable without them. Regards, Mikhael.
Re: FVWM: buttons that don't pop back
On 20 Oct 2005 07:35:32 -0700, Joseph Mack NA3T wrote: On Thu, 20 Oct 2005, Dominik Vogt wrote: Just remember that both, 2.2 and 2.4 come with scripts to convert your config to the new format. OK have fetched -2.2.5 too This is not needed at all. The script names posted earlier are for 2.5.x. In 2.4.x, the same scripts reside in utils/ under slightly different names, fvwmrc_convert means fvwm-convert-2.2. Anyway, most of your config should not change at all. good to know Anyway, it is good to replace any obsolete syntax. Regards, Mikhael.
FVWM: Mailing list archive
On 19 Oct 2005 17:48:03 +0200, Julien Guertault wrote: Sorry if this is a FAQ. BTW, can someone point me to an archive of this list that goes back more than a month? http://www.mail-archive.com/fvwm@fvwm.org/ This is severely incomplete. I only see one message for 2004, and that's spam :-) I understood the usual mailing list archive was www.hpc.uh.edu and is now down. But hopefully someone has more information. Some parts of the archive are in: http://www.mail-archive.com/fvwm@hpc.uh.edu/ http://www.mail-archive.com/fvwm@lists.math.uh.edu/ The last location contains more recent messages. mail-archive.com says it is possible to unite all of these 3 into one (actually feed one message by one), but this is quite a work... The same is correct for fvwm-workers@ instead of [EMAIL PROTECTED] Maybe someone has another united archive. Regards, Mikhael.
Re: FVWM: buttons that don't pop back
On 19 Oct 2005 07:14:44 -0700, Joseph Mack NA3T wrote: I looked for a FAQ on the fvwm.org site but only found the man pages, so sorry if this is a FAQ. Do you mean you don't see the word FAQ or/and icon looking like ? on the home page? :) I have fvwm-2.0.43. I know this is old, but I'm happy with my setup and don't want to rewrite my .fvwm2rc file to use the new syntax. Well... But also think about us needing an extra effort to remember the old syntax and the old problems from many years ago when answering. What do I need to do to make the button pop back up on launching the program. Here's the xv button line from my .fvwm2rc file *FvwmButtons XV xv.color.xpm Exec XV xv Your problem is that the resource name of xv is XVRoot, not XV. Although this ambiguous syntax is still supported, the new way is: *FvwmButtons: (Title XV, Icon xv.color.xpm, Action Exec XV* xv) Regards, Mikhael.
FVWM: Offtopic: reposting my messages
It seems either my local mutt or sendmail have problems. When I reply to someone + list (since I don't know whether he is subscribed) the message to the list is sometimes lost. Please, if your mailer allows, setup Mail-Followup-To: fvwm@fvwm.org header, so others know automatically not to cc you. In mutt, it is subscribe fvwm@fvwm.org line in muttrc. I will repost 3 messages that I think were lost. Probably there are more. Regards, Mikhael.
Re: FVWM: Mailing list archive
On 19 Oct 2005 20:11:09 +0200, Julien Guertault wrote: http://www.mail-archive.com/fvwm@fvwm.org/ http://www.mail-archive.com/fvwm@hpc.uh.edu/ http://www.mail-archive.com/fvwm@lists.math.uh.edu/ [...] mail-archive.com says it is possible to unite all of these 3 into one (actually feed one message by one), but this is quite a work... Do you have a link please? I don't find this information on their website... Probably in their FAQ. I remember their pages said they may add aliases manually on request, when I added fvwm and fvwm-workers lists several years ago. Since I don't have a time for this, I am all for someone to contact their team [FAQ: How can I import existing archives?] and give them raw archives to import, and verify that everithing is done correctly, including aliases, i.e. all messages end up under @fvwm.org/ urls. Or setup another online mail archive browser with search (again, import existing raw archives and subscribe to new messages). Regards, Mikhael.
Re: FVWM: [FVWM-THEMES] Configuration error
On 09 Oct 2005 07:30:13 +1000, Felix Karpfen wrote: My attempts to enable sound from the FVWM -Theme Settings screen failed with the following error message: , | Unexisting variant `` in component `settings/gnome/user-menu` ` which, unfortunately, I do not understand. I can't reproduce this problem. I would supposedly need the output of grep -17 file=settings/gnome/user-menu ~/.fvwm/themes/current/theme.cfg to see why you got this error at all. Does it help to change the settings / GNOME / User Menu from the menu? If it does not help, then choose Reset all to the default in the menu. Regards, Mikhael.
Re: FVWM: Statically compiled FVWM?
On 09 Oct 2005 23:21:06 +0300, Octavian G. wrote: The main question (for now) is wether there is a list of dependencies (libs, other software) associated with the build of either the stable or the unstable relase. I'm interested in compiling FVWM statically, and I'd like some directions if there isn't some paper I actually missed. If so, please link me, and accept my appologies. All optional library dependancies are listed in ./configure output. They are explained in details in INSTALL.fvwm file. There are no mandatory library dependancies except for ones coming with pretty much any POSIX operating system and any X. So I see no good reason to compile fvwm statically. Regards, Mikhael.
Re: FVWM: FvwmEvent killed
On 10 Oct 2005 19:48:07 +0200, Miroslav Zubcic wrote: However, I have one weird problem with FvwmEvent(1). I'm using fvwm 2.4.19 (stable), and have one FvwmScript(1) module/script which is taking action from FvwmEvent(1) with SendToModule. This does not work always as expected. Sometimes (4-5 times a day) fvwm freezes and waits ModuleTimeout seconds, and then kills FvwmEvent(1). Problem is occuring (temp. freeze) when I change desks (not pages on local desk) with transient pager spawned by FvwmButtons(1). This is error from ~/.xsession-errors: [FVWM][PositiveWrite]: ERROR Failed to read descriptor from 'FvwmEvent': - data available=N - terminate signal=N This is usually happens when some kind of deadlock occured between fvwm and modules. The offending module may then be killed after ModuleTimeout. Note, the problem may be something not fvwm related. For example, if some other processes take all CPU, then FvwmEvent may fail to answer in time. Can you please try to reproduce this problem with 2.5.x or cvs? Small work was done in this direction (although I rarely experience such problems too, with non-trivial event callbacks and modules defined.) This is my Fvwm-Event.cf (included from ~/.fvwm/.fvwm2rc): *FvwmEvent: new_desk FuncSendToDeskNo *FvwmEvent: new_page FuncSendToDeskNo *FvwmEvent: add_window FuncAddWindowEvent This is function FuncSendToDeskNo: DestroyFunc FuncSendToDeskNo AddToFunc FuncSendToDeskNo + I SendToModule *FvwmApplet-DeskNo SendString 10 9 $[desk.n] + I SendToModule *FvwmApplet-DeskNo SendString 10 10 $[desk.n]$[page.nx]$[page.ny] I suppose you meant FvwmApplet-DeskNo without an asterisk here. Regards, Mikhael.
Re: FVWM: Configure bug
On 14 Oct 2005 12:56:18 +0400, George Nephrite Potapov wrote: I don't know if this bug is fvwm team's fault, but here it is. I configure cvs version (after all automake/autoconf stuff, of course) like this: configure --with-png-includes=/usr/local/include \ --with-png-library=/usr/local/lib It successfully executes and says that I WILL have PNG support. But then I run make and it fails with message /usr/bin/ld: cannot find -lpng I looked into generated Makefiles and there is a line png_LIBS=-lpng see, the -L/usr/local/lib stuff's missing! I corrected it manually, but of course it is a bug in configure script or whereever it is. What do you say? Which system do you use? To read about the solution, please run: grep -10 LDFLAGS INSTALL.fvwm Regards, Mikhael.
Re: FVWM: sliding panel?
On 09 Oct 2005 08:44:12 -0700, Zack Brown wrote: I'd like to configure the FvwmButtons module (or anything with similar use) so it will slide out of the right edge of the screen when I hold my mouse pointer against that wall, and retract when the mouse leaves. Is there a way to do this? http://fvwm.org/documentation/faq/#7.17 Regards, Mikhael.
Re: FVWM: env variables -- single point of care
On 07 Oct 2005 21:29:37 -0600, Jonathan Kotta wrote:
This should work from a PipeRead. I didn't test it very carefully.
You probably have to be more careful with the '$'s.
source ~/.bashrc /dev/null ;
for i in $(env) ;
do echo $i | sed -e s/^/SetEnv / -e s/=/ '/ -e s/$/'/ ;
done
You don't really need for if you pipe from env, like:
env | gawk --field-separator = '{ printf SetEnv %s `%s`\n, $1, $2 }'
This includes all variables that are already defined in the fvwm process,
and some of them may include the ` character. If one wants to be more
minimalistic than this, then he may create mini-script vars2fvwm:
something_exporting_shell_variables # like: source ~/.profile /dev/null
env | sed -e 's/^/SetEnv /' -e 's/=/ `/' -e 's/$/`/'
and call it like: PipeRead `env -i vars2fvwm`. Note -i.
Of course, this approach is for new variables only. Constant variables
are better to be set once, before fvwm is started.
Regards,
Mikhael.
Re: FVWM: env variables -- single point of care
On 07 Oct 2005 14:10:33 +0200, Julien Guertault wrote: Is there an easy way to make FVWM somehow read/source the env vars I set in .bashrc/.zshrc? I don't know if there is any other way more appropriate to do so, but you can use PipeRead. For instance: DestroyFunc InitFunction AddToFunc InitFunction + I PipeRead 'source .bashrc /dev/null' The variables set from .bashrc here will affect the sub-shell only. They have no any influence upon the fvwm process. Regards, Mikhael.
Re: FVWM: Feature request: desktop pages larger than the screen?
On 29 Sep 2005 13:35:57 -0700, Zack Brown wrote: On Thu, Sep 29, 2005 at 04:53:35PM +, Mikhael Goikhman wrote: On 29 Sep 2005 09:04:06 -0700, Zack Brown wrote: It would be nice to be able to specify the page size at startup. A lot of folks run maximized xterms with no window decorations, just because if they expanded the window to keep the decorations outside of the screen, the decorations would encroach on neighboring pages. Having a page size larger than the screen size would fix this. I think you simply want to have a command to switch a window into full-screen mode and back. Just use this: DestroyFunc FuncFvwmMaximizeFullScreen AddToFunc FuncFvwmMaximizeFullScreen + I ThisWindow (Maximized) WindowStyle Title, Borders + I TestRc (!Match) WindowStyle !Title, !Borders + I TestRc (!Match) Raise + I TestRc (!Match) UpdateStyles + I Maximize ewmhiwa Key F11 A SC Pick FuncFvwmMaximizeFullScreen I considered this, but there are problems. For one thing, having maximized, borderless xterms right next to each other leaves no empty desktop area to click in to call up a menu. This is not really a priblem, you may bind any mouse or keyboard action in W (client window). And if you prefer an empty desktop place, then do Maximize 100 95 or something like this. For another, a maximized xterm with no borders will extend slightly into the neighbording pages, which is ugly. This is not true, a maximized window fully fits one page only. In the case of a terminal (that defines a step-like resize) there will be usually a free space left even with Maximize 100, not the other way. Variable page sizes would solve this problem elegantly. I don't think so. Can you give some reason? I don't see any drawback to variable-sized pages. It's just an elegant solution to any situation where you want portions of the window to extend beyond the edge of the screen, without encroaching on neighboring pages. I don't see how variable-sized pages may solve any problem at all. Do you also mean one page may be 800x600 and another 1200x900? Will sticky windows just disappear in the hole? Please give concrete numbers, what is your resolution, what is your border width, title height, and what do you suggest for the page size. Regards, Mikhael.
Re: FVWM: gtk+ 2.0
On 23 Sep 2005 08:09:07 +, George Krajcsovits wrote: holly molly, that patch is from 2002 ! Was that the last of it ? Ok, I'm joining fvwm-workers now. Please don't top-post on these lists. I may be mistaken, but I don't remember seeing more updated patches. On 9/22/05, Mikhael Goikhman [EMAIL PROTECTED] wrote: On 22 Sep 2005 09:11:14 +, George Krajcsovits wrote: I'm sure this came up before, but the archive search doesn't work for me. Is there a version / CVS branch of fvwm2 that supports gtk+ version 2.0+ ? I have little spare time, but I'd be happy to contribute if needed, after all this is just porting... This is a bit more than just porting. Please start with this thread: http://www.mail-archive.com/fvwm-workers@hpc.uh.edu/msg01344.html We will gladly receive your contribution on fvwm-workers list. Regards, Mikhael.
Re: FVWM: NoteMessage in home dir?
On 24 Sep 2005 20:43:38 +, Mikhael Goikhman wrote: On 24 Sep 2005 12:00:23 -0400, Wendell Turner wrote: I copied that file from [...] to my home directory Nothing in fvwm searches in the home page. This claim is also true, but I meant home directory. :) Regards, Mikhael.
Re: FVWM: ALT+mouse button window moves
On 22 Sep 2005 11:31:43 +, George Krajcsovits wrote: I'm testing 2.5.14 and when I try to move a window (ALT+MouseButton1 inside window) it starts the move only after I let go of the button. In 2.4.15 it used to move immediately, and kept on moving as long as I kept the button pressed. How do I get the old style back ? You should create and bind a function that does Move, not Move directly. This was asked way too many times on this list. I think we should either restore the previous behaviour or add it to FAQ. Regards, Mikhael.
Re: FVWM: gtk+ 2.0
On 22 Sep 2005 09:11:14 +, George Krajcsovits wrote: I'm sure this came up before, but the archive search doesn't work for me. Is there a version / CVS branch of fvwm2 that supports gtk+ version 2.0+ ? I have little spare time, but I'd be happy to contribute if needed, after all this is just porting... This is a bit more than just porting. Please start with this thread: http://www.mail-archive.com/fvwm-workers@hpc.uh.edu/msg01344.html We will gladly receive your contribution on fvwm-workers list. Regards, Mikhael.
Re: FVWM: fvwm installation
On 21 Sep 2005 22:10:29 -0700, Phechploy Chirachaisakul wrote: Now, I'm using fvwm2 and I want to upgrade it to fvwm version 2.4.19 or 2.5.12. Anyway, I've already download both of these files from you website, but I don't know what should I do next or how to install it because my unix knowledge is not quite well. Could you explain me the way to install or upgrade it in step by step? It is up to you to choose the stable or unstable branch, but please use the latest 2.5.14, not 2.5.12, if you choose so. Regards, Mikhael.
Re: FVWM: rearranging icons in the IconBox ?
On 21 Sep 2005 12:49:20 +0300, [EMAIL PROTECTED] wrote: I have IconBox, regular good old IconBox. I want to manually reorder icons in the IconBox by dragging/moving them dragging them inside IconBox. Is there any extension, or a property of IconBox that allows me to manually drag/move icons inside IconBox ? The answer is unfortunately no. Regards, Mikhael.
Re: FVWM: Where to start debugging?
On 17 Sep 2005 22:45:28 -0400, Thomas A. Horsley wrote: Right. I exit fvwm, then restart it in an xterm. It really does read my rc file because some of the stuff happens (just not all of it). Ah-HA! More interesting info: The very first mouse click works fine (whichever feature I try acts normally on the first mouse click, all my definitions seem to be there), but following the first click (even if I exit and restart fvwm), all I see is a the default menu on button 1, my customizations are all gone. I have to completely exit the NX session and start a new one, then the first mouse click in that one works. All your bindings use N modifier, so they will stop working once you press NumLock or similar. Use A instead, and see FAQ #0.1 for more. You may add Echo message 1 debug commands (even in the middle of menu) to verify the commands you think are executed are actually executed. Regards, Mikhael.
Re: FVWM: mozilla vs. firefox style settings
On 03 Sep 2005 15:41:31 +0200, Karl Berry wrote: I'd like to have different IconFont settings for mozilla and firefox. Is it possible? What I tried was this: Style *ozilla* IconFont *-times-bold-i-normal-*-14 Style *irefox* IconFont *-times-bold-r-normal-*-14 But both come out in bold roman. I am not sure if there's any way to distinguish them in the world of X resource names. I can't reproduce this. If I type your lines in FvwmConsole, I get different icon fonts for mozilla and firefox. Consider to use less fuzzy patterns to reduce unintentional matches: Style Mozilla IconFont *-times-bold-i-normal-*-14-* Style Firefox-bin IconFont *-times-bold-r-normal-*-14-* Also, check your Style * IconFont lines, the order matters. Regards, Mikhael.
Re: ManualPlacement/Move Patch
On 01 Sep 2005 07:10:25 +0200, Viktor Griph wrote: On Wed, 31 Aug 2005, Mikhael Goikhman wrote: On 31 Aug 2005 21:42:20 +, Mikhael Goikhman wrote: This is not enough, To emulate the current logic you should also add: Mouse 1 P N CancelPlacement Mouse 2 P N CancelPlacement I.e. if you started the Move using button 1, then button 2 cancels it and vice versa. Since you can't press button 1 again while dragging using button 1, these binding would be ok although not immediately intuitive. Well, actually these will not be ok if the Move is started on mouse click (not drag) or on key press. So either we conclude your idea can't work or we may try to somehow save it using, say, this extension: Mouse 0 P N PlaceWindow Mouse 1 P(d0) N CancelPlacement Mouse 2 P(d0) N CancelPlacement Mouse 1 P(d1) N PlaceWindow Mouse 2 P(d2) N PlaceWindow Mouse 2 P(c) N CancelPlacement Where dN means dragging using button N and c means mouse click or key press. No, I am not a big fan of such idea, but I am not against either. (I think the current logic about Move cancelation is good.) I've not changed the logic for dragging of windows. IT's only the interactive movment that my patch affects. I maybe should make that more clear in the manual page. I did see no need to try to change the drag logic, as all feeling on how it should work matches with how it currently does. I.e you hold down the button the drag started with and calcel the movement by pressing any other button. Well, this is not exactly what happens now. If you drag using mouse button 1 or 2, then button 3 places the window, rather than cancels. I suppose Dominik intentionally did it to allow PlacedByButton3 using dragging too. If you want to be able to use some buttons for placing the window evenif it is being dragged it could probably be conficured by also changing PlaceWindow to always place the window and add PlaceWindowInteractive and PlaceWindowDrag as well as CancelPlacementDrag/CancelPlacementInteractive, and maybe also add CancelPlacement for completness, even if it would be the same as -. However, I think that just would comlicate things. But if you think it would be better to be able to define that you want to be able to place a window you are dragging by clicking on another button as well I can try to add that. You see, this is not enough. There should be at least the special notion of the same button that started the drag. The bindings quoted above should be implemented in one or another way (either configurable or hard-coded). I am not sure the flexibility you want to add is either needed or easy to implement (if possible at all). It is like to allow a user to create a new menu feel (key and mouse bindings) using a configuration. The menu code is messy and there are many actions and special cases already without configurable bindings. I don't know whether users want or have the ability to replace the placement feel with some usable alternative. Can you partition the exact current feel into configurable commands and estimate the work needed to implement this? Something along lines: Key Return P A PlaceWindow Key Space P A PlaceWindow Key Escape P A CancelPlacement Key Right P A MoveWindow +10p 0 Key Right P S MoveWindow +100p 0 Key Right P C MoveWindow +1p 0 Key AltP C ToggleSnapAttraction # well, this is a modifier, not a key If you show this is possible, then we may think to add a half-hardcoded command like CancelWithOppositeButton1Or2 to support the drag mode. How should the PlacedByButton n condition be affected by a drag move? I think the flags should be immediately reset on any Move and only set when the placement was not canceled. Also, just for info, I think it is acceptable that currently Pick Move and Move work differently in no window context. The first does interactive Move. The second starts dragging on mouse click and does interactive Move on key click (Enter). I think I have to move the assignment of PlacedByButton to the start of ButonRelease instead of the end of ButtonPress for best functionality. I'll not sublit a new patch for just that until I know if you want the ability to place dragged windows with another button than the drag started with or not. Regards, Mikhael.
Re: ManualPlacement/Move Patch
On 31 Aug 2005 21:42:20 +, Mikhael Goikhman wrote: This is not enough, To emulate the current logic you should also add: Mouse 1 P N CancelPlacement Mouse 2 P N CancelPlacement I.e. if you started the Move using button 1, then button 2 cancels it and vice versa. Since you can't press button 1 again while dragging using button 1, these binding would be ok although not immediately intuitive. Well, actually these will not be ok if the Move is started on mouse click (not drag) or on key press. So either we conclude your idea can't work or we may try to somehow save it using, say, this extension: Mouse 0 P N PlaceWindow Mouse 1 P(d0) N CancelPlacement Mouse 2 P(d0) N CancelPlacement Mouse 1 P(d1) N PlaceWindow Mouse 2 P(d2) N PlaceWindow Mouse 2 P(c) N CancelPlacement Where dN means dragging using button N and c means mouse click or key press. No, I am not a big fan of such idea, but I am not against either. (I think the current logic about Move cancelation is good.) Regards, Mikhael.
Re: Notification: incoming/1291
On 30 Aug 2005 17:20:59 +0300, Evgeny Stambulchik wrote: Mikhael Goikhman wrote: Fine, I would like to apply this patch. Thanks! I have modified the patch slightly, so it only calls frame_get_titlebar_dimensions once, not 8 times. But please fix borders for windows without title (WindowStyle !Title), they are still quite bad with your new patch. Right, but this seems to me a genuine fvwm bug elsewhere related to the X expose events. Try switching focus to/off such a window several times; at the end, when focus is off, the borders are drawn just fine. Ok, I will let Dominik to answer. Without fixing this problem we will need to restore the previous bg.pixmap.g.x = bg.pixmap.g.y = 0; code. To reproduce the problem: BorderStyle TiledPixmap /some/image.xpm WindowStyle !Title, Handles, HandleWidth 20 Then pick and focus/unfocus any window. Regards, Mikhael.
Re: FVWM: Alignment and partition of FvwmIconMan
On 28 Aug 2005 14:00:22 +0800, 志新谭 wrote: When I try to swallow FvwmIconMan into FvwmButton, I want the effect that all icon in a row, with max width 150, a frame in the perimeter and align from left to right, just like in gnome. But these two lines doesn't work, it always align from center, further more it seems all icon with the same color and fuse in one, is there any other options? All options are documented in man FvwmIconMan. You want MaxButtonWidth option introduced in 2.5.13. *FvwmIconMan: ManagerGeometry 0x1+0+0 *FvwmIconMan: ButtonGeometry 150x0 These options are quite tricky. For your specific case I suggest to do: *FvwmIconMan: ManagerGeometry 5x1+2+2 *FvwmIconMan: ButtonGeometry 50x30 where 30 matches the height you defined in FvwmButtons for FvwmIconMan (say, 600x30). In fact, values 5, 1 and 50 in these lines will be more or less ignored (they should just be nonzero). Regards, Mikhael.
Re: FVWM: Detecting FixedPosition windows
On 17 Aug 2005 16:10:54 -0500, Jonathan Kotta wrote: On 8/16/05, Mikhael Goikhman [EMAIL PROTECTED] wrote: On 16 Aug 2005 18:02:47 -0500, Jonathan Kotta wrote: I would like to make a function to toggle a window between fixed and movable styles, e.g. DestroyFunc ToggleMovable AddToFunc ToggleMovable + I ThisWindow (FixedPosition) WindowStyle VariablePosition + I TestRc (NoMatch) WindowStyle FixedPosition But of course there is no FixedPosition condition. It seems weird to me that FixedSize is available but FixedPosition isn't. Am I missing something, or is this feature not available at present? It is not in conditional.c, feel free to submit a patch. I tried my hand at hacking fvwm, and I think I was successful. It works for me, anyway. Please rewrite to keep the existing indentation (TAB, not 4 spaces), add changes to files NEWS, AUTHORS and ChangeLog, and submit to [EMAIL PROTECTED] Regards, Mikhael.
FVWM: Working with variables defined by SetEnv
On 14 Aug 2005 12:13:12 +0200, Brice Méalier wrote: it seems that removing: + I UnsetEnv Icon-$[w.id] does the trick! I didn't dig into your original problem. Probably there is some synchronization issue that your trick may fix. BTW how can I visualize the environment variables defined by SetEnv? Suppose we defined some variables: SetEnv valid_shell_var value SetEnv non-inherited-var 42 is the meaning of life You may get the list of all valid environment variables using: Exec xterm -e env | less You can't get the list of invalid shell variables, because they are not passed to the child processes (although this is system specific). But you may get their value using $[var-name] syntax, as usual: Echo $[non-inherited-var] I don't really think that using variable names that include dashes or other funky chars should be encouraged. This depends on the behaviour of putenv/getenv system functions. Anyway, it seems to work on my system. If you use the cvs version, you may also check whether some var is set, or to test its value, using this syntax: Test (EnvIsSet non-inherited-var) Beep Test (EnvMatch non-inherited-var *life) Exec xmessage $[non-inherited-var] P.S. In your specific case there is an issue of double expanding (i.e. the var name itself is not static). An additional expanding is currently only possible using PipeRead (we would need a new Expand command), but the rest is still the same. Regards, Mikhael.
