Re: Patching FvwmButtons to use Balloons (tooltips).
Hi Thomas, (I have no doubt if we get this right, FvwmIconMan might follow, since this has an applicable use for balloons also.) I got the impression from Olivier's post a while back that there is already such a patch for FvwmIconMan. http://thread.gmane.org/gmane.comp.window-managers.fvwm.devel/713 Scott. :)
Re: Manpage fix for 2.5.17: Wait command.
Hi Thomas, I noticed earlier that there is a discrepency in the FVWM manpage (2.5.X series is the only one to be fixed) for the Wait command description. The description says initially that the command waits of windowname. This is parly true -- the code in builtins.c apparently also checks for the window's tile, class and resource (just like how the style command works). I feel this needs to be reflected in its description ... +.BI Wait [ windowtitle | windowclass | windowresource ] Personally, I think it would be prudent to stick with windowname here. A novice user might think it appropriate to specify, say, a window resource then be surprised to learn that some other window with a matching _title_ was matched. How about: Wait windowname This command is intended to be used in fvwm functions only. It causes execution of a function to pause until a new window matching windowname appears. A window can match windowname on either its title, class or resource. This is particularly useful in InitFunction if you are trying to start windows on specific desks or pages: It's still not perfect - any suggested improvements? Note that in the function example accompanying the Wait command's description, I have taken the liberty of replacing the function's use of the Desk command with GotoDesk since this is now the preferred command to use. Ok. ThisWindow (thomas_adam) Destroy ThisWindow (thomas_adam) Wait godo :) Scott. :)
Re: Manpage fix for 2.5.17: Wait command.
ThisWindow (thomas_adam) Wait godo :) Ah, that was supposed to be godot. Scott. :)
Re: FVWM crashes with $[0]
I think there is a bug in FVWM's parameter expansion. FVWM crashes with a simple command such as: Echo $[0] Is this supposed to be fixed? FVWM still crashes on my system when I type Echo $[0] in FvwmConsole. __eae_parse_range() is screwy: sscanf(input, %u-%n, ... returns 1 when input = 0. (which is the case for $[0]) Then variable 'n' has some undefined value which causes an illegal memory access at expand.c:232 Scott. :)
more on expansion behaviour
Hi all, Help please. addtofunc fn + i echo executing $[0-] + i $[0-] fn echo hello How come fn doesn't print out hello? Scott. :)
Re: Tabs implementation question
Hi David, I'm trying to find out how to have multiple windows sharing the same frame. I'm playing with FvwmTabs but I also want to experiment with a simpler implementation on my own. Simpler? H. I just want to get four functions working - add, next, close and detatch tab. That is enough functionality for what I want to do. I want to see what would be possible if it was integrated into fvwm. Most of the features you talk about are already possible with the FvwmTabs module or could be implemented without too much effort. It would remove the need to create a tabber first - just join any two windows together I've been using the following function to combine create add commands into a single action: # CreateTabberWithWin will put the focused window into a new tabber, # creating it at the same position as the window. DestroyFunc CreateTabberWithWin AddToFunc CreateTabberWithWin + I Current (!FvwmTabs) SetEnv CTWW_ID $[w.id] + I TestRc (NoMatch) Break + I PipeRead 'echo SetEnv CTWW_COUNT $(( $CTWW_COUNT+1 ))' + I NewTabber --geometry=+$[w.x]+$[w.y] .$[CTWW_COUNT] + I Wait FvwmTabs* + I WindowId $[CTWW_ID] Tabize .$[CTWW_COUNT] Key Z A CM CreateTabberWithWin To combine additional add commands into the same action would just require the use of the MultiAddTab function. and also remove the second title bar *FvwmTabs: showTitlebar false - it could be integrated into the main one. *FvwmTabs: useTMTitlebar true The aim would be to make it transparent to the user rather than offering alot of functionality and configuration. I agree that it's a pain that FvwmTabs depends on external libraries (X11::Protocol Tk) which can make configuration difficult for some users. I don't think I've ever heard a user complain about too much functionality though! (Some people complain about Emacs, but that's different! :) It's just an idea I wanted to play around with based on how pekwm does this. Go right ahead - the more people hacking on FVWM the better! IMHO. You need to use XSetInputFocus(). The client window does get input focus and works normally, except that the frame decor isn't changed when the focus does. The event handlers aren't called so I can't think of anywhere to put this that would work. I also think that it is a problem with events in general and not just input focus. Sorry, that's a little too cryptic for me to understand. I assume you know you have to ask the X server which events you're interested in (for each window) right? This is usually accomplished by setting the event mask with XChangeWindowAttributes(). Scott. :)
Bees
Damn this list is busy! http://gmane.org/plot-rate.php?group=gmane.comp.window-managers.fvwm.develwidth=1000height=400color=red,orange,%234000title=fvwm-workerssmooth=exp Not that I'm complaining. Scott. :)
Re: FVWM crashes with $[0]
I think there is a bug in FVWM's parameter expansion. FVWM crashes with a simple command such as: Echo $[0] Is this supposed to be fixed? FVWM still crashes on my system when I type Echo $[0] in FvwmConsole. I am using current version of CVS. Scott.
Re: Tabs implementation question
Hi David, I'm trying to find out how to have multiple windows sharing the same frame. I'm playing with FvwmTabs but I also want to experiment with a simpler implementation on my own. Simpler? H. I wrote something like the following in the main fvwm code. Add tab: (client is the fw-wins.client from another frame) XReparentWindow(dpy, client, fw-wins.parent, 0, 0); XResizeWindow(dpy, client, fw-frame_g.width, fw-frame_g.height); XLowerWindow(dpy, client); XUnmapWindow(dpy, client); Next tab: (fw-wins.client is advanced by a linked list) XMapWindow(dpy, fw-wins.client); XRaiseWindow(dpy, fw-wins.client); XSaveContext(dpy, fw-wins.client, FvwmContext, (caddr_t) fw); rectangle frame_g = fw-frame_g; frame_force_setup_window( fw, frame_g.x, frame_g.y, frame_g.width, frame_g.height, True); When I switch to another tab, the window works as normal except it doesn't recieve FocusIn/Out events. This stops the focus decor from changing when the mouse is in the window. When I switch back to the first tab, it works properly. There seems to be something special about the first client window because it was originally in that frame. I thought setting FvwmContext would give each client the exact same structure but it doesn't. HandleFocusIn is never called except for the first window. I'm just wondering, what is the solution to this? You need to use XSetInputFocus(). SCoTT. :)
Re: KillModule fix
Hi Renato, The attached patch fixes the broken KillModule command. Can someone please apply it? Done. How long was it broken? Not long. Since 2006/06/24. By the way, I've long wanted to know the significance of seventh guardian ... ? SCoTT. :)
PeekToken GetNextToken
Hi Dominik, Some hints for using the parsing functions Thanks. I think they are useful, so I added them as comments to the source code. (slightly modified) By the way, I notice that entries in ChangeLog appear not to be in chronological order. I always use the local date - I assume that's ok? Scott.
Re: Periodic command
Hi Dominik, Can you have multiple peridic commands or just one? Multiple. I suggest to replace the command Periodic with some option to the Schedule command The current specification for Schedule is: Schedule delay_ms [command_id] command So, would something like the following do? Schedule delay_ms [command_id] [Periodic] command Perhaps someone has a better suggestion? SCoTT. :)
Periodic command
Hi all, Here is a proposed patch to add a new builtin function, Periodic. http://members.optusnet.com.au/scottsmedley/fvwm/periodic.patch Apply with: patch -p0 periodic.patch It is similar to the Schedule builtin except the function is invoked every N milliseconds - even if a grab fails, or the function fails to execute for some other reason. It will allow the user to do something like: Periodic 1000 Echo Testing the Periodic builtin. Deschedule $[schedule.last] Periodic 1000 42 Echo Testing Periodic with explicit command Id. Deschedule 42 Please tell me what you think of this proposed functionality. SCoTT. :)
Re: Grabbing and complex functions
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? SCoTT.
Re: Grabbing and complex functions
Hi Dominik, Well, it has all been discussed in that old thread. Many of the issues surrounding how _FVWM_ might detect if a function needs to grab or not have been discussed, I agree with you - it's going to be very, very difficult ... at best. However, I feel that Dan's idea (to allow the _user_ to specify if a function needn't grab) didn't receive the discussion it merited. Maybe because the discussion had deteriorated quite a bit by the time he suggested it ...? The fact that fvwm needs to grab the pointer in some cases is mostly unrelated to the action's type. Some complex functions need to grab the pointer to make sure the user or other applications does not interfere with function execution: Agreed. * The user might push or release a mouse button which causes EnterNotify/LeaveNotify events that can confuse (immediate) complex functions that raise or lower windows or fiddle with the focus (or do other things that I can not think of). We once tried to remove the grab, and functions using Raise/Lower + WarpPointer + Focus could not do their job anymore. * What would commands like Move or Resize be good for without a grab? Fvwm would freeze until the grab ends. * The PointerWindow command could have very undesirable results without a grab. For example, I have something like this in my config: Key d A SCM my_close AddToFunc my_close + I Silent PointerWindow Close If the pointer can be warped by an application during function execution, a random window might be closed. * You can not even know which commands need to run in case of Read or PipeRead. I agree with all of that. I agree that a failed grab can cause lots of problems. Hopefully it's clear that many immediate functions may need the grab too. Yes. But I have no idea how to decide if a certain function needs it or not. Me neither. My question about what to do with a non-immediate condition in a NoGrab function was about whether such a case was a blatant error. I've no intention of writing code to catch all abuses of NoGrab. If we could somehow miraculously implement the black-list you mention there'd be no need for a NoGrab option in the first place, because FVWM could determine all by itself whether a grab was required. I accept that it is too difficult to do this, which is why I think allowing the user to specify NoGrab when it's needed would be an acceptable compromise. I would agree to a nograb patch if it 1) *enforces* proper operation, i.e. refuses to define nograb functions that are potentially unsafe. AND 2) adds useful functionality (doubtful, considering the length of the blacklist above). By this metric, I openly admit that the DefineFunc patch fails on requirement 1). IMHO, other posts already show that (even if we were to restrict the available functions) a NoGrab option will still be useful. Having said that, I feel that requirement 1) is a little draconian. I share your concern for restricting _anything_ unsafe in FVWM. However, I don't think the DefineFunc patch is particularly unsafe. The default behaviour is always to grab; it doesn't break any existing configs; users will never notice a difference in behaviour unless they _explicitly_ use NoGrab. (A minority of users?) Then, the onus is upon the user to use NoGrab in a valid way - it's only here that there is scope for misuse. With a properly documented entry in the man page, I hope this will be rare. Before I end this post I just want to repeat my main point: By using the NoGrab option, the decision not to grab the pointer is made by the _user_, not _FVWM_. SCoTT.
Re: Grabbing and complex functions
Hi Mikhael, 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. You would have had my vote! :) Do you have a URL so I could read up on the discussion? I would say that AllImmediate flag is redundant (may be a default). This may be discussed after 2.6.0. If we make it a default (after 2.6.0) that might make backwards-compatibility difficult. SCoTT. :)
Re: Grabbing and complex functions
Hi Mikhael, 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. Good idea. It is ok by me to add DefineFunc before 2.6.0, if it fixes issues. Particularly, will it fix reliability of (re-)Schedule? 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. With the proposed modifications, NoGrab functions will not be prone, to this failure. ie. if Schedule invokes a NoGrab function, it will execute - even if the pointer is grabbed by some other app. This patch is available at: http://members.optusnet.com.au/scottsmedley/fvwm/defineFunc.patch Apply with: patch -p0 defineFunc.patch A question about the implementation: Given this function DefineFunc MyFunc NoGrab + I Echo hello world + C Echo click should FVWM generate a warning (or error?) about using a non-I (immediate) condition within a NoGrab function? Perhaps reverting the function to a normal Grab function? 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. SCoTT. :)
Re: Grabbing and complex functions
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. SCoTT.
Re: ModuleListenOnly command
Hi Dominik, Are you enjoying the World Cup? Two reasons: (1) Schedule is an unreliable hack and (2) this starts a shell every 15 seconds and my goal was to waste as little cpu as possible (as it interferes with certain time-critical applications - okay - games). Hehe. :) Re: (2) From some rudimentry tests I've performed on my Linux laptop, using 'sh' adds little overhead. Your CPU usage is going to be swamped by 'ps'. 'ps' performs ~1000 system calls [1], whereas 'sh' performs 116 system calls [2] - an 11% overhead. Plus you've got a 'sort' in there which is nearly another 100 system calls. 'sh' isn't going to take any longer as the number of processes increases, but 'ps' 'sort' will. I realise the number of system calls isn't a direct measurement of CPU usage, but it's a pretty good metric for the issues you're considering here. In short, I'm not sure adding a new builtin command to Fvwm to speedup an arcane situation (by _at best_ 10%) is really worth it, IMHO. I am prepared to write FvwmButtonsUpdater for you (using perllib) if you need the extra 10% performance, but I can't promise how much faster it will be. Re: (1) Having just looked into how Schedule execute_complex_function() work, I'm not prepared to blame Schedule just yet. In my opinion, I don't think FVWM should grab the X server everytime it executes a complex function. I realise it's necessary when the function references the Motion/Click/Hold/Double modifiers but in the majority of cases, most user functions will just use Immediate. [3] This makes me think it would have been nice to separate AddToFunc into 2 separate commands - AddToMouseFunc AddToFunc. Where AddToMouseFunc would permit modifiers, AddToFunc would _always_ assume an Immediate modifier. As a hack/compromise, maybe we could modify AddToFunc to keep track of whether or not it uses a mouse modifier only then grab the X server, in execute_complex_function(). Thoughts? SCoTT. :) [1] strace -o /tmp/o /bin/ps -A --format %C %P %c ! /tmp/ps.out wc -l /tmp/o [2] strace -o /tmp/o sh -c : ; wc -l /tmp/o [3] I've no data to support this, except for my own config where I rarely use a modifier other than Immediate.
Re: ModuleListenOnly command
Hi Dominik, That's just one purpose of the command. I was always fond of the idea to prototype or even implement modules as shell scripts. Yes, that would be cool. IMHO, I think it would be prudent to create bashlib (akin to perllib), instead of adding ModuleListenOnly command. But I suppose that should be a 2.6 feature? It is certainly possible to handle input from fvwm to the module in the script itself, but hard to guarantee that the input is processed in a timely fashion Why is that? Re: grabbing and complex functions. I'll reply to this in a new thread with a more appropriate subject. SCoTT. :)
Grabbing and complex functions
Hi Dominik et al, This post follows on from the previous ModuleListenOnly command which was getting a bit off-topic. As a hack/compromise, maybe we could modify AddToFunc to keep track of whether or not it uses a mouse modifier only then grab the X server, in execute_complex_function(). We discussed this a couple of years ago, and Olivier(?) suggested to allow functions without grabbing. The problem is that it is generally unpredictable which functions need to grab and which do not, and you can't do it on the fly because its too late then. I see. I read the thread (posted by Thomas) now I understand that the grab is necessary for more than just the use of mouse modifiers, I agree that it's near-impossible to calculate in advance whether we need to do a grab before we execute a complex function. As an author of complex functions, though, I sometimes know I do _not_ want FVWM to perform a grab when it executes my complex function. Would anyone be adverse to allowing the user to specify when they do not want a grab to be performed? Dan suggested something like this in: http://www.mail-archive.com/fvwm@lists.math.uh.edu/msg10120.html I'm not so keen on adding 'Grab' 'Ungrab' builtin commands. (It's not too hard to image novice users regularly causing FVWM to freeze, through misuse of such commands.) But I like the idea of specifying a function as being NoGrab. Dan proposed FunctionNoGrab FUNCNAME. Another way to do it would be: AddToFunc MyFunc NoGrab I Echo hello + I Echo world but I think this a bit unintuitive/hackish. Instead, I propose adding a separate builtin command, DefineFunc: DefineFunc MyFunc NoGrab + I Echo hello + I Echo world DefineFunc would behave much like AddToFunc except for 3 differences: 1. It would generate a warning message if the function already existed. 2. It would _not_ accept an action. 3. It would accept a list of _optional_ function options. To start with, the only option would be NoGrab. We could actually modify AddToFunc in this way, but (2) is a rather significant interface change could upset a lot of users. Note that use of DefineFunc wouldn't be mandatory (though we could easily detect if it wasn't used generate a deprecated warning if we wanted to) it doesn't change the behaviour of existing configs. (ie. functions defined soley using AddToFunc) What do you think? SCoTT. :)
Re: ModuleListenOnly command
Hi Dominik Mikhael, 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. Why use a module for something so simple? AddToFunc MyPeriodicFunc + I PipeRead 'echo SendToModule FvwmButtons ChangeButton clock Title $(date +%R %a %d.%m.)' + I PipeRead 'str=$(/bin/ps -A --format %C %P %c | sort -n -r | tail -n1) ; echo SendToModule FvwmButtons ChangeButton topproc Title $str' + I Schedule 15000 MyPeriodicFunc Schedule 3000 MyPeriodicFunc The topproc calculation can be tidied up. This is just a proof-of-concept. SCoTT. :)
Re: ModuleListenOnly command
+ I PipeRead 'str=$(/bin/ps -A --format %C %P %c | sort -n -r | tail -n1) Sorry, that should be 'head', of course. (or drop the '-r' flag on 'sort'.) SCoTT. :)
Re: Possible patches
Hi David, I've created a patchset[1] to try to improve the way fvwm looks. Who wrote each of these patches? I just created an updated version of the RoundedCorners patch that applies cleanly against current CVS, for anyone who wishes to try it (without requiring all the other patches on your site): http://members.optusnet.com.au/scottsmedley/fvwm/fvwm.roundCorners.patch SCoTT. :)
PATCH: if-elsif-else-endif syntax (v3.0)
Hi all, An updated version of my if-syntax patch that applies cleanly against current CVS is available at: http://members.optusnet.com.au/scottsmedley/fvwm/if.20060609.patch Example usage: http://members.optusnet.com.au/scottsmedley/fvwm/if.example All feedback welcome. SCoTT. :)
Re: CVS scott: Ok, FvwmTabs is ready to try out now.
But running a quick make distcheck yields... Making all in FvwmTabs make[4]: Entering directory `/home/awol/cvs/fvwm/fvwm-2.5.15/_build/modules/FvwmTabs' make[4]: *** No rule to make target `FvwmTabs.pod', needed by `FvwmTabs.1'. Stop. Thanks, fixed. Now make dist works fine but make rpm-dist and deb-dist does not. I've never succeeded in getting rpm-dist deb-dist to work. (Well, out-of-the-box anyway.) Please tell me if I've broken anything in these 2 builds during the addition of the FvwmTabs module. SCoTT. :)
Re: FvwmTabs module
i find that it's a pity that there isn't a simple and useful behavior of FvwmTabs like in Fluxbox. Indeed, in Fluxbox you just have to move the title bar of a window to another one and the two titlebar are one. I've never used Fluxbox but from what you say it sounds like the drag--drop feature of FvwmTabs does something similar. Have you tried this in your fvwmtabrc file? *FvwmTabs: enableSwallowDND true or just use the Swallow Overlapping (DD) option in the menu. Then just move any existing window over an FvwmTabs window it should be swallowed automatically. I find FvwmTabs too complexe There are certainly many options - users like to use it in many different ways. Suggestions to improve FvwmTabs are always welcome (as are patches!). SCoTT. :)
FvwmTabs module
Hi all, Before the end of this month my personal website which hosts the FvwmTabs module associated documentation will be shutdown. 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? If not, I can update the webpages put them on my new personal website. SCoTT. :)
Re: Frappr Map: Fvwm
As you can see by the weather report, there are some baloons over the usa/canada and the north of europe. One guy caught some wind and ended up on australia though.. LOL Yeah, it's a bit lonely in my solitary balloon over here. :) I hope I can join you soon in my baloon :) I'll be over Portugal though. As soon as I finish my FvwmXevie module and qualify as a real contributor.. Oh I think it's for Fvwm users as well. You should add yourself. The more Fvwm-balloon-buddies the better! What does your FvwmXevie module do? SCoTT. :)
FVWM on FC3
Hi all, Is anyone running a recent version of FVWM on Fedora Core 3? I compiled 2.5.12 CVS versions from source last night on a fresh FC3 install it hung consistently (using default config). Didn't have much chance to investigate other than a few stack traces: (gdb) where #0 0x008dc7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x009b2cfd in ___newselect_nocancel () from /lib/tls/libc.so.6 #2 0x00a7df92 in _XEnq () from /usr/X11R6/lib/libX11.so.6 #3 0x00a7e36e in _XRead () from /usr/X11R6/lib/libX11.so.6 #4 0x00a7f4cb in _XReply () from /usr/X11R6/lib/libX11.so.6 #5 0x00a7a0f6 in XSync () from /usr/X11R6/lib/libX11.so.6 #6 0x0808ab8e in frame_move_resize (fw=0x9d6b8d8, mr_args=0x9d8f7b8) at frame.c:1024 #7 0x0808b966 in __frame_setup_window (fw=0x9d6b8d8, frame_g=0xfefa9d90, do_send_configure_notify=1, do_force=1, is_application_request=0) at frame.c:396 #8 0x0808bb34 in frame_force_setup_window (fw=0xfdfe, x=0, y=0, w=0, h=0, do_send_configure_notify=1) at frame.c:2056 #9 0x080ab344 in apply_window_updates (t=0x9d6b8d8, flags=0xfefaa218, pstyle=0xfefaa220, focus_w=0x9d6b8d8) at update.c:364 #10 0x080abad4 in flush_window_updates () at update.c:713 #11 0x080653d9 in HandleEvents () at events.c:3841 #12 0x08085b96 in main (argc=1, argv=0xfefab024) at fvwm.c:2520 (gdb) where #0 0x008dc7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x009b2cfd in ___newselect_nocancel () from /lib/tls/libc.so.6 #2 0x00a7df92 in _XEnq () from /usr/X11R6/lib/libX11.so.6 #3 0x00a7e36e in _XRead () from /usr/X11R6/lib/libX11.so.6 #4 0x00a7f4cb in _XReply () from /usr/X11R6/lib/libX11.so.6 #5 0x00a6629c in XGetGeometry () from /usr/X11R6/lib/libX11.so.6 #6 0x08063fa1 in HandlePropertyNotify (ea=0xfee86b74) at events.c:3106 #7 0x08065343 in dispatch_event (e=0xfee86bc0) at events.c:3804 #8 0x08065409 in HandleEvents () at events.c:3849 #9 0x08085b96 in main (argc=1, argv=0xfee87824) at fvwm.c:2520 So I thought I'd ask if anyone else has problems on FC3 before I start debugging ... SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: PATCH: if-elsif-else-endif syntax (v2.0)
Hi Uwe, :) I would mostly use it for statemente like AddToMenu my_menu if ! ShellCmd /opt/myprogram + My Program menu Menu my_program_menu endif This should be possible.? Yup, it works no problem. SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
PATCH: if-elsif-else-endif syntax (v2.0)
Hi all, Someone recently asked me about the status of if-syntax in Fvwm. This inspired me to readdress an earlier patch I wrote (which was somewhat limited in scope a bit buggy) to identify the issues hack up a robust implementation. This new patch: - ensures there are no race conditions b/w modules - allows nested if statements - allows if statements in functions - is very intuitive (IMO) - is not yet documented in the man page Some example syntax: # A simple if-statement. If Any (xterm) Echo An xterm session is running Elsif Any (rxvt) Echo An rxvt session is running Else Echo No xterm/rxvt sessions running EndIf AddToFunc ToBeOrNotToBe + I Echo To be or not to be? That is the question ... + I If ShellCmd uname -a | grep -q -i linux + I Echo To be! :) + I Else + I Echo Not to be. :( + I Endif Further examples are available at: http://users.tpg.com.au/users/scottie7/tmp/config.if Developers interested in this patch will probably want to read this thread: http://www.hpc.uh.edu/fvwm/archive/0108/msg00044.html To apply this patch, download: http://users.tpg.com.au/users/scottie7/tmp/if.patch run: cd $fvwm_src_dir patch -p0 if.patch make install Any comments/criticism most welcome. SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Parsing window_flags in perl
Does anyone happen to know the status of the work that was proposed in this thread? http://www.hpc.uh.edu/fvwm/archive/0409/msg00094.html SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
CopyToken()
Hi Dominik, :)
After revision 1.61 of libs/Parse.c, DoPeekToken() is behaving very
oddly. Best illustrated with an example:
If I pass a string, say, 2.5.13 to DoPeekToken() with delimiters .,
I get back the token 2 (correct) but the pointer to the rest of the
string (the actual return value) is .13 which is incorrect. (The '5'
character got truncated in CopyToken().)
+ t = SkipSpaces(src, spaces, snum);
+ if (*t != 0 dnum strchr(delims, *t) != NULL)
+ {
+ src = t + 1;
+ }
I think the strchr() needs to be replaced with a function that
checks for delims at the _start_ of t (not just anywhere in t).
But I'm not really sure what your intention was, hence why I'll
leave it to you to fix.
I noticed this problem because the following syntax no longer works:
Test (Version = 2.5.11) Echo yup
Seeya!
SCoTT. :)
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm-workers in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Parsing window_flags in perl
o I am writing a fvwm perl module and anticipate wanting to parse the o window_flags data upon receiving each M_ADD_WINDOW event The proper solution is to serialize the flags without dumping C structures. Here is a discussion: http://www.hpc.uh.edu/fvwm/archive/0407/msg00186.html Let's see if I understand this thread properly. (Tell me if I say something incorrect.) At the moment, whenever FVWM sends an M_ADD_WINDOW or M_CONFIGURE_WINDOW packet, the last field in the packet is (effectively) a memcpy() of the window_flags data-member from the ConfigWinPacket struct. The bit-value of the window_flags data-member varies from compiler to compiler because of byte alignment/padding, endianess, etc. So the solution is to define precisely what each bit in a flags field (of a packet) pertains to. This means that FVWM will carefully build each bit in the flags field (selectively choosing only 50 or so interesting flags from the window_flags struct). FVWM modules that receive these packets now have to treat the flags field as a specially-defined set of bits (relating directly to flags) instead of a bundle of bits that fill a window_flags C struct. Presumably we have to ensure that the 50 (or so) flags we decide to export satisfy all the C FVWM modules. (Currently, the modules have access to all 384 bits (on my platform) of the window_flags struct could potentially be using any of them.) Re: perllib breakage is auto-detected I'm not sure how perllib would detect the addition or removal of flags. SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: man pages have wrong date
The very last line of all the man pages (with the notable exception of fvwm.1) appears to have an arbitary date (hardcoded from the source man page). I just commited a patch to parse all man pages through config.status. This involved renaming most *.1 files to *.1.in. Several man pages appear to be auto-generated by Perl scripts: ./bin/fvwm-menu-directory.1 ./bin/fvwm-menu-headlines.1 ./bin/fvwm-menu-xlock.1 ./bin/fvwm-perllib.1 ./modules/FvwmDebug/FvwmDebug.1 ./modules/FvwmDebug/FvwmGtkDebug.1 ./modules/FvwmPerl/FvwmPerl.1 ./modules/FvwmWindowMenu/FvwmWindowMenu.1 So I've not changed these. I'm not sure if I need to make any further changes to complete this patch. For example, when making a release, will scripts automatically pickup the new *.1.in files ignore the *.1 files? SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: man pages have wrong date
Create FvwmButtons.1.in, a Makefile entry run it through config.status? (like the fvwm.1 man page) I'm having trouble determining the configuration (in fvwm/Makefile.am?) that creates this target in fvwm/Makefile.in: fvwm.1: $(top_builddir)/config.status fvwm.1.in cd $(top_builddir) $(SHELL) ./config.status $(subdir)/$@ Can anyone offer a clue on how the fvwm.1 target is created? Initially, I created an explicit target: FvwmButtons.1: $(top_builddir)/config.status FvwmButtons.1.in cd $(top_builddir) $(SHELL) ./config.status $(subdir)/$@ in fvwm/modules/FvwmButtons/Makefile.am, but this seems kinda hackish given that the fvwm.1 target is generated automatically. (somehow) SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FvwmButtons
Hi Dominik, :) I don't think the event is wrong. When a complex function is executed, fvwm grabs the pointer. Ah! I see. FvwmButtons handles LeaveNotify events only, so the final LeaveNotify unhilights the button. I've committed a fix. Also, drawing of panel buttons was wrong during the panel animation (fixed too). Excellent. (Referring to the fixes, not the bugs, of course. :) If such a feature is worthwhile it use an entirely separate colour set (SwallowColorset or WaitColorset or ...). Okay. We are currently out of bits in b-flags. This field is an unsigned int (4 bytes on Linux). Can we change it to an unsigned long long int? (8 bytes) I'm not sure what ramifications this has on other architectures. SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FvwmButtons
Hi Dominik, :) It seems to happen only if a function is called, not with plain commands. Try DestroyFunc foo AddToFunc foo I nop DestroyModuleConfig FvwmButtons* *FvwmButtons: ActiveColorset 2 *FvwmButtons(Title foo, Action foo) Module FvwmButtons This is a bizarre bug! The button is actually redrawn (correctly) with the active colorset, but the FvwmButtons module immediately receives a LeaveNotify event (I don't move the mouse) redraws the button with the standard colorset (thinking that the mouse cursor is no longer in the FvwmButtons window). You can also do: sleep 6 FvwmCommand foo whip the mouse into _any_ button wait for the LeaveNotify event to get triggered (causing the active button to be drawn in the standard colorset, instead of the active one). So, why does invoking function foo cause FvwmButtons to receive an erroneous LeaveNotify event? SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FvwmButtons
Hi Dominik, :) You misunderstood me. In short, when I said click I meant press + release. Try this: - Use an ActiveColorset. It does not matter whether you use the PressedColorset too. - Move the mouse over a pressable button to hilight it. Don't move any more during this test. - Press the mouse button. - Release the mouse button. == The button is no longer hilighted - Move the mouse. == The button gets hilighted again. I can't reproduce this either. The button is highlighted just fine after I release the mouse button (without moving the mouse). I know this was a bug in the first version I committed to CVS. I know it's (very!) unlikely, but I don't suppose you're running an older version? :) SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FvwmButtons
Hi Dominik,
Currently, the Active{Colorset,Title,Icon} are used. If none are
specified then Colorset, Title Icon are used. The effect you
describe is achievable by setting PressColorset to the same colorset
as your ActiveColorset (formerly HoverColorset). I'm undecided if
this is the right behaviour ...
I think this is the right behaviour - it's the main reason we have
PressColorset, PressIcon PressTitle in the first place. It doesn't
make sense to override them with the Active* options.
Things get complicated when no Press* options are specified, but the
current behaviour is still coherent when a button is waiting for a
window to popup ( the active button could be elsewhere).
Okay.
But with the latest patch, almost all the bugs I fixed a couple of
days are back (which is no big surprise as most or all of the code
I changed is gone).
1) After clicking on a button it is no longer hilighted.
This is what I was talking about (see above). Presumably you have
no PressColorset specified are using an action like:
Action Exec xmessage exec xmessage hello
Maybe you'd like an option to override the Press* options with the
Active* options (what's the point of having Press* options then?).
I suppose an option to override Press* options with Active* options
if--only-if no Press* options are specified could be warranted ...
2) Press mouse button 1 on a button without releasing it. It now
is drawn with PressColorset.
Press button 2 without moving the mouse to cancel the action.
== the button is drawn using the normal colorset while it
should use the ActiveColorset.
Yep. A bug - will fix soon.
3) Press and hold a mouse button over a button. It gets
hilighted as it should. Then move the pointer out of the
button into another button.
== It is still hilighted and sunken, but should be raised and
not hilighted.
4) Same as (3), but move the pointer out of the FvwmButtons
window.
3 4: The current behavior is as Mikhael requested. See earlier
posts. (Maybe I misinterpreted?)
Would you please consider backing out your latest changes and redo
them without removing the code I wrote?
With only one minor bug, hopefully I've convinced you this isn't
necessary. Of course, if you still feel that it is necessary I will comply.
In the interests of harmonious future collaboration I'd like to air
a couple of thoughts:
It's a bit frustrating having multiple people working on exactly the
same bit of code. One could argue that this is the nature of distributed
projects. However, I like to think that most of the time this can be
avoided. In this case, it was clear I was working on the FvwmButtons
module - if a similiar situation were to arise in the future, can I
suggest just requesting me to fix bugs /or make implementation changes?
This would prevent me from effectively undoing your changes which must
be equally frustrating for you.
Upon reflection, maybe I caused this problem by not checking in my
bugfixes earlier. By my logic, there were no showstoppers (mostly
minor cosmetic bugs) in CVS, so I kept fixes in my own tree for a
couple of days so I could thoroughly test while I added a couple of
other features. Perhaps I should commit fixes as soon as they are
done? Don't know. All suggestions/discussion on the way I work on
FVWM most welcome.
Anyway, I hope this discussion isn't inappropriate. I'm hoping some
clear communication now will enable me to avoid causing futher problems
later on.
SCoTT. :)
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm-workers in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: FvwmButtons
Hi Dominik,
When I click on any button, it ends up using the
standard colour set until the mous is moved. That has nothing to
do with the PressedColorset.
Ok, this must be a bug - I will check/fix tonight.
Another problem that is going to become worse in the future is
code that is correct by the C99 standard but not by C89
(specifically C++ style comments with // and declarations in the
body of code blocks, e.g. { int i; i=1; intj; }). Is there an
option to tell gcc to adhere to the C89 standard?
gcc -std=c89 ...
This works for me. (I'm using gcc 3.2.2) It detects both '//'
loop declarations reports them as errors.
Very handy, as I'm sure I would otherwise let '//' comments slip
through ocassionally. It's too ingrained! :)
SCoTT. :)
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm-workers in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
FvwmButtons
Hi all,
1 When you click a button, it is drawn in the original colours as
long as the mouse button is held. Shouldn't it also use the
HoverColorset?
Currently, the Active{Colorset,Title,Icon} are used. If none are
specified then Colorset, Title Icon are used. The effect you
describe is achievable by setting PressColorset to the same colorset
as your ActiveColorset (formerly HoverColorset). I'm undecided if
this is the right behaviour ...
4 When the pointer is on a container or a swallowed application,
the border of that container is hilighted. I think only
buttons that actually have an action bound to them should be
hilighted (maybe this should be configurable).
TODO.
5 I'm not sure Hover is a good name. I associate all kinds of
things with hovering, but definitely not the current
behaviour. In the menu code we use Active for that purpose.
Done.
SCoTT. :)
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm-workers in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: HoverIcon for FvwmButtons (Was: animated FvwmButtons)
But the option Pixmap none don't work properly, ie it doesn't have a transparent background as expected. Still TODO. The way transparency is implemented with Pixmap none is a bit hacky (IMO), especially when we're moving toward Colorsets. But I s'pose it should be backwards-compatible ... SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FvwmButtons
1 When you click a button, it is drawn in the original colours as
long as the mouse button is held. Shouldn't it also use the
HoverColorset?
Currently, the Active{Colorset,Title,Icon} are used. If none are
specified then Colorset, Title Icon are used. The effect you
describe is achievable by setting PressColorset to the same colorset
as your ActiveColorset (formerly HoverColorset). I'm undecided if
this is the right behaviour ...
I think this is the right behaviour - it's the main reason we have
PressColorset, PressIcon PressTitle in the first place. It doesn't
make sense to override them with the Active* options.
Things get complicated when no Press* options are specified, but the
current behaviour is still coherent when a button is waiting for a
window to popup ( the active button could be elsewhere).
SCoTT. :)
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm-workers in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Saving Windows: save stacking order?
Hi Mikhael, :)
Ok, I have implemented the generic looped args support, so M_RESTACK
is now fully supported.
Thank-you muchly!
One problem: I'm running a simple module get this error:
Internal error, event type 1 (11 names, 7 values)
Also FVWM::Window::dump in WindowList.pm looks dodgy. I had to change it to:
sub dump ($) {
my ($window) = @_;
my $id = $window-{win_id};
my $string = Window $id\n;
foreach my $prop (sort keys %$window) {
next if $prop =~ /^_/;
$string .= \t$prop:\t[$window-{$prop}]\n;
}
return $string;
}
to get it to compile, but I'm not sure if that's right.
I think you should take a look at FvwmPager, it is the only module
currently that manages stacking order of windows.
Will do, thanks.
SCoTT. :)
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm-workers in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
man pages have wrong date
I just got confused by the FVWM man pages. The very last line of all the
man pages (with the notable exception of fvwm.1) appears to have an arbitary
date (hardcoded from the source man page).
For example, the FvwmButtons man page from the 2.5.10 release has this line:
3rd Berkeley Distribution 23 September 2002FvwmButtons(1)
You can see all the dates with this command:
find . -name '*.1' -exec /bin/grep ^.TH {} \;
What is the correct solution for this?
Create FvwmButtons.1.in, a Makefile entry run it through config.status?
(like the fvwm.1 man page)
Additionally, I think it would be nice to specify the version of FVWM
that each man page applies/belongs to in the actual man page. The fvwm.1
man page has this.
Thoughts?
SCoTT. :)
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm-workers in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: CVS scott: Apply conditionals patch.
Committed patch by Norman Yarvin (with a few minor mods) to extend conditionals to handle multiple window names. Hm, I did not expect this to be committed with the option naming issue unresolved I was not aware of this issue. This is the first post I've seen discussing it. I saw Mikhael's proposal (liked it) audited/tested Norman's subsequent patch to make sure it did what Mikhael suggested. Did I miss other posts on the topic? Either way, I'm sorry to have caused a problem. SCoTT. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: matchVersion() compile problems
Hi Dominik, :)
To avoid problems with comiling / reading the fvwm sources, please
* adhere to the ANSI-C 88 standard, not the new one.
Specifically,
- Don't use C++-like comments with //
- Declare variables only at the beginning of a block.
* limit your lines to 79 characters (if possible, do not use 80
characters - I can't get xemacs to start with 80 columns, it
either has 79 or 81 because of the font I use).
Sure. No problem.
* Please put single statements in loops or if clauses in curly
braces, i.e.
if (1)
{
foo;
}
not
if (1)
foo;
What's the rationale behind this? I must confess I'm not particularly fond
of this restriction but I will, of course, follow any FVWM coding standards.
SCoTT. :)
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm-workers in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: matchVersion() compile problems
* Please put single statements in loops or if clauses in curly
braces, i.e.
if (1)
{
foo;
}
not
if (1)
foo;
What's the rationale behind this? I must confess I'm not particularly fond
of this restriction but I will, of course, follow any FVWM coding standards.
From docs/CONVENTIONS:
o Always place curly braces on a separate line. In some cases,
placing braces on the same line as other code confuses
(x)emacs.
Wouldn't it be prudent to fix Emacs?
(That's an honest question, not trying to start an xemacs-vs-gvim war.)
SCoTT.
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm-workers in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: Building FVWM in separate directories
automake creates a bunch of system-dependent soft-links: depcomp - /usr/share/automake-1.7/depcomp* install-sh - /usr/share/automake-1.7/install-sh* missing - /usr/share/automake-1.7/missing* mkinstalldirs - /usr/share/automake-1.7/mkinstalldirs* When I ./configure on another machine those links are broken. If the file systems on these machines are not identical then run automake --add-missing --copy, not automake -a. This works perfectly - thanks Mikhael! :) SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Patch to allow multiple window names in conditions
Hi Norman, About a month ago, I sent in a patch to allow multiple window names in conditions. I think being able to specify multiple windows in conditions is very useful. It's 2:30am ... let me see if I understand your patch correctly: If you have: Next (mozilla dillo netscape) Function ... The relationship b/w mozilla, dillo netscape is a LOGICAL OR. but if I have: Next (!mozilla !dillo !netscape) Function ... the relationship is a LOGICAL AND. Have I got that right? If I have, I'm concerned users might get confused. (I'm sure other people edit their .fvwm2rc at 2:30am too! :) I'll sleep on it. SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Building FVWM in separate directories
Hi Mikhael, :) Out of tree builds should work. If not, then it is a bug. For example, this should work: cd /nfs/cvs/fvwm aclocal autoheader automake -a autoconf cd /build/mysystem /nfs/cvs/fvwm/configure [params] make make install Just tried this on the fresh cvs checkout, works perfectly without writing anything system dependent to the checkout directory. automake creates a bunch of system-dependent soft-links: depcomp - /usr/share/automake-1.7/depcomp* install-sh - /usr/share/automake-1.7/install-sh* missing - /usr/share/automake-1.7/missing* mkinstalldirs - /usr/share/automake-1.7/mkinstalldirs* When I ./configure on another machine those links are broken. SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Building FVWM in separate directories
Is it possible to build FVWM in separate directories? ie. a bit like how GCC is built. I'd like to have a NFS-mounted directory with CVS source code then build it for several systems. SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Notification: incoming/1335
Hi Piotr, Piotr use FakeClick to intercept clicks in some windows, and pass the Piotr click to the others ... Scott The correct way to do this now is with a window-specific binding. ie. Scott Mouse (rxvt) 1 A N Echo mouse1-in-rxvt Scott Mouse (xterm) 1 A N Echo mouse1-in-xterm Thanks! Works perfectly. Just a quick question: what's the meaning of Mouse (xterm) 1 A N Command1 Mouse 1 A N Command2 Will Command2 be executed for an xterm window or not? No. Window-specific bindings take precedence over global bindings. SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Notification: incoming/1335
Hmmm, I thought specifying fvwm-workers@fvwm.org in the notification list (of the fvwm-bug website) would ensure this note got sent to the list - obviously not: use FakeClick to intercept clicks in some windows, and pass the click to the others ... The correct way to do this now is with a window-specific binding. ie. Mouse (rxvt) 1 A N Echo mouse1-in-rxvt Mouse (xterm) 1 A N Echo mouse1-in-xterm Note that this feature is currently in CVS will be available in 2.5.11. xdvi should react to such a click I can't reproduce your problem. It worked fine for me with: sleep 2 FvwmCommand 'FakeClick depth 0 press 1' The sleep is so I have time to move the mouse cursor to the xdvi window. SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
fvwm-bug account (Was: TODO 2.6)
You may go to http://www.fvwm.org/cgi-bin/fvwm-bug.private (password needed) and manage bugs. Username 'scott' my CVS password don't appear to work. Who should I see about this? Jason? SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: fvwm-bug account (Was: TODO 2.6)
You may go to http://www.fvwm.org/cgi-bin/fvwm-bug.private (password needed) and manage bugs. Username 'scott' my CVS password don't appear to work. Who should I see about this? Jason? You don't appear in the pull down list of people with access. I think you need Jason to add you. Ok, thanks Dan. Jason, can you please give me access to fvwm-bug? Also, DEVELOPERS should probably be updated. The Doing the JitterBug section implies anyone with CVS access has access to fvwm-bug. SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
TODO 2.6
Hi Mikhael, What needs to be done for items E.11, E.12 E.15 in docs/todo-2.6? Oh! I just noticed item F.1! :) SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Proposal: new default config
Hi all, The default config for FVWM is (IMO) yuk! I propose we update it to actually make it usable also to make it a little more aesthetically pleasing. As an initial step, find attached a .fvwm2rc file. This syntax could be added to ConfigFvwmDefaults ( SetRCDefaults() in fvwm.c potentially updated as well). A screenshot is available here: http://users.tpg.com.au/users/scottie7/tmp/defaultLook.png I would like to emphasise that the goal is NOT to have a whiz-bang, super-dooper config showing off all FVWMs bells whistles! (For that we have custom .fvwm2rc files (hi Tavis! :) fvwm-themes, etc.) The default config should remain simple with a reasonable level of intuitive functionality ... but it also shouldn't look like FVWM got stuck in the 90's! :) All comments/suggestions/criticism most welcome. SCoTT. :) Style * Color AntiqueWhite/RoyalBlue Style * HilightFore Yellow, HilightBack MidnightBlue Mouse 0 1 A Menu DefaultButton1Menu Mouse 1 2 A Close Mouse 3 2 A Destroy Mouse 1 4 A Maximize Mouse 3 4 A Maximize False Mouse 1 6 A Iconify Mouse 3 6 A WindowShade Mouse 1 I A Iconify off Mouse 3 R A WindowList DestroyMenu DefaultButton1Menu AddToMenu DefaultButton1Menu + Close Close + Destroy Destroy + Iconify Iconify + Maximize (toggle) Maximize + Move Move + Resize Resize + WindowShade (toggle) WindowShade MenuStyle * MenuFace DGradient 255 1 RoyalBlue 100 antiquewhite MenuStyle * ActiveFore white # Not sure about gradients on the titlebars. TitleStyle Active HGradient 255 2 MidnightBlue 50 black 50 MidnightBlue TitleStyle InActive HGradient 255 2 RoyalBlue 50 black 50 RoyalBlue
Re: Proposal: new default config
Hi Mikhael Dominik, :) Dominik says: : The default config for FVWM is (IMO) yuk! : You obviously never took a look at sample.fvwmrc/system.fvwm2rc Perhaps my definition of default config is wrong. To me, this is an example .fvwm2rc file that users have to explicitly copy to ~/.fvwm/config or wherever. (Incidentally, this file does not appear to be installed with make install.) I was more interested in the look usability of FVWM when no ~/.fvwm2rc, ~/.fvwm/config, etc file is found. : 1. It has to support black/white displays. Surely we can get around this with PipeRead xdpyinfo, or (even better) FVWM probably knows when it's running on a monochrome display. : 2. I am highly reluctant to add new mouse or key bindings. see next point. Mikhael says: : I see some problems with your specific suggestion. The more bindings you : define (especially uncommon ones) the more users should undo in their : configs. What if we made FVWM Read a default config file iff no config file is found in the usual places? Maybe we should make it read system.fvwm2rc? : The colors are sharp, they are not very pleasant for a long work, so I : see no real improvements in this area. I'm not married to any of the aesthetics - just anything other than grey black! :) : You use 3 titlebar buttons on the right without redefining their look. : It is very bad that a button looking like Maximize does Close. Good point. : I have no final opinion yet. But if you absolutelly want to have a new : default look and feel, then I suggest to borrow it from the default theme : of the current fvwm-themes cvs. Ah! Good idea! I guess I'm trying to guard against this situation: Newbie tries FVWM for the first time. Starts it up. YUK!. (never uses FVWM again) Maybe it doesn't happen as much as I think it does. Still, my hypothetical newbie gets a vastly different experience when trying fvwm-themes, KDE, Gnome, etc for the first time. SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Somthing broken in fvwm-snap-20040608!
Hi Liu, : Stroke behave strangely, the latest stroke sequence overrides : all previous stroke sequences. Ok, fixed. Please email future bug reports to the fvwm-workers list, not the fvwm list. Most subscribers to the fvwm list aren't interested in bug reports. Thanks for testing. :) SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Somthing broken in fvwm-snap-20040608!
: - Key binding in the Root context won't work, for example : Key F1 RMExec exec rxvt : it won't start rxvt but pop up the default menu instead. : - StrokeFunc in the Root crashes X, for example: : Mouse 1 RNStrokeFunc DrawMotion FeedBack StrokeWidth 2 : now when you click the Root, you'll exit X and there is no error msg. Reverted to previous behaviour which was to activate the _last_ matching binding. The stroke problem should be fixed too. You can try it out in CVS or wait for snap-20040610. SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
win-specific bindings syntax (was: CVS write access for Scott?)
Hi Dominik, : I think we should give CVS write access to Scott. Anybody to : second that opinion? Can I vote? :) : (To Scott: I know I promised to look more closely at the window : specific key bindings patch, but I just don't find the time to do : it since I became a freelancer. I think the functionality is : fine. The only concern I have was something about the interface. : If you'd write an example binding line I will remember immediately : what it was.) Sure. Here's an extract from an earlier post: === Syntax is: Key Tab (FvwmTabs)A C Function NextTab Now, Ctrl-Tab in an FvwmTabs window invokes the NextTab function whereas in any other window the key event is passed through to the window with the focus. Other examples: Key V (rxvt)A C Echo ctrl-V-in-RXVT Key V (xterm)A C Echo ctrl-V-in-XTerm Key V A C Echo ctrl-V-elsewhere The only difference is an optional regex-pattern field denoting the window class/resource/name (appearing in ()-brackets at the _START_ of the context field) that the binding applies to. === It seems I neglected to mention that it works with Mouse bindings as well. SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
PATCH: Window List Tracker FvwmWindowMenu
Hi Mikhael, :)
Find attached a patch that includes the WindowList tracker
updated FvwmWindowMenu module which actually utilises the new
tracker.
Comments most welcome.
SCoTT. :)
Index: modules/ChangeLog
===
RCS file: /home/cvs/fvwm/fvwm/modules/ChangeLog,v
retrieving revision 1.1110
diff -u -r1.1110 ChangeLog
--- modules/ChangeLog 1 Jun 2004 11:46:54 - 1.1110
+++ modules/ChangeLog 2 Jun 2004 11:28:48 -
@@ -1,3 +1,10 @@
+2004-06-01 Scott Smedley [EMAIL PROTECTED]
+
+ * FvwmWindowMenu/FvwmWindowMenu.in:
+ * FvwmWindowMenu/FvwmWindowMenu.1:
+ Rewrote module to use new WindowList tracker.
+ Updated man page.
+
2004-06-01 Dominik Vogt [EMAIL PROTECTED]
* FvwmConsole/FvwmConsoleC.c (main):
Index: modules/FvwmWindowMenu/FvwmWindowMenu.1
===
RCS file: /home/cvs/fvwm/fvwm/modules/FvwmWindowMenu/FvwmWindowMenu.1,v
retrieving revision 1.2
diff -u -r1.2 FvwmWindowMenu.1
--- modules/FvwmWindowMenu/FvwmWindowMenu.1 12 Nov 2003 21:27:41 -
1.2
+++ modules/FvwmWindowMenu/FvwmWindowMenu.1 2 Jun 2004 11:28:50 -
@@ -128,8 +128,8 @@
.rm #[ #] #H #V #F C
.\
.\
-.IX Title FVWMWINDOWMENU 1
-.TH FVWMWINDOWMENU 1 2003-11-12 perl v5.8.1 FVWM Modules
+.IX Title FVWMWINDOWMENU.IN 1
+.TH FVWMWINDOWMENU.IN 1 2004-06-02 perl v5.8.1 FVWM Module
.SH NAME
FvwmWindowMenu \- open configurable fvwm menu listing current windows
.SH SYNOPSIS
@@ -149,13 +149,14 @@
module does not draw its own window, but instead creates an
\\fIfvwm\fR menu and asks \fIfvwm\fR to pop it up.
.PP
-By defining a set of regular expressions using Show, windows may
-be sorted into sections based on the regexp matching their
-name, icon name, class or resource.
+By defining a set of regular expressions, windows may
+be sorted into sections based on a regexp matching the window
+name, class or resource and included in the menu.
.PP
-Similarly, matches in DontShow will be excluded from the list.
+Similarly, another set of regular expressions can be used to exclude
+items from the menu.
.PP
-Any windows not matching an instance of Show or DontShow will
+Any windows not matching an instance of the include or exclude list will
be placed in the last section of the menu.
.SH USAGE
.IX Header USAGE
@@ -186,41 +187,44 @@
\\fBMenu\fR and \fBPopup\fR. If the module was started with \*(L\-g\*(R
switch, it
additionally supports \fBPostBar\fR (not implemented yet).
.PP
-Set module options for windows to show or not show. The syntax is:
+Set module options for windows to include (Show) or exclude (DontShow).
+The syntax is:
.PP
-.Vb 2
-\*FvwmWindowMenu: Show type = pattern
-\*FvwmWindowMenu: DontShow type = pattern
+.Vb 6
+\*FvwmWindowMenu: ShowName pattern
+\*FvwmWindowMenu: ShowClass pattern
+\*FvwmWindowMenu: ShowResource pattern
+\*FvwmWindowMenu: DontShowName pattern
+\*FvwmWindowMenu: DontShowClass pattern
+\*FvwmWindowMenu: DontShowResource pattern
.Ve
.PP
-where type is one of \fIname\fR, \fIicon\fR, \fIclass\fR or \fIresource\fR.
Pattern is
-a perl regular expression that will be evaluated in m// context.
+Pattern is a perl regular expression that will be evaluated in m// context.
See \fIperlre\fR\|(1).
.PP
For example:
.PP
.Vb 2
-\*FvwmWindowMenu: Show resource = Galeon|Navigator|mozilla-bin
-\*FvwmWindowMenu: Show name = ^emacs
+\*FvwmWindowMenu: ShowResource ^gvim
+\*FvwmWindowMenu: ShowName Galeon|Navigator|mozilla-bin|Firefox
.Ve
.PP
-will define two sections containing respectively browsers, and emacs.
-Number of sections is unlimited. The strings are perl regular
-expressions that will be evaluated in m// context. See \fIperlre\fR\|(1).
+will define two sections containing respectively browsers, and GVim. A third
+section will contain all other windows.
.PP
Similarly:
.PP
.Vb 2
-\*FvwmWindowMenu: DontShow name = ^Fvwm
-\*FvwmWindowMenu: DontShow class = Gkrellm
+\*FvwmWindowMenu: DontShowName ^Fvwm
+\*FvwmWindowMenu: DontShowClass Gkrellm
.Ve
.PP
will cause the menu to ignore windows with name beginning with Fvwm
or class gkrellm.
.PP
Other options:
-.IP *FvwmWindowMenu: \fIOnlyIconic\fR {on|off} 4
-.IX Item *FvwmWindowMenu: OnlyIconic {on|off}
+.IP *FvwmWindowMenu: \fIOnlyIconified\fR {on|off} 4
+.IX Item *FvwmWindowMenu: OnlyIconified {on|off}
show only iconified windows
.IP *FvwmWindowMenu: \fIAllDesks\fR {on|off} 4
.IX Item *FvwmWindowMenu: AllDesks {on|off}
@@ -228,8 +232,8 @@
.IP *FvwmWindowMenu: \fIAllPages\fR {on|off} 4
.IX Item *FvwmWindowMenu: AllPages {on|off}
show windows from all pages
-.IP *FvwmWindowMenu: \fIMaxlen\fR 32 4
-.IX Item *FvwmWindowMenu: Maxlen 32
+.IP *FvwmWindowMenu: \fIMaxLen\fR 32 4
+.IX Item *FvwmWindowMenu: MaxLen 32
max length in chars of entry
.IP
PATCH: make FvwmCommand handle SIGPIPE cleanly
Hi all, FvwmCommand currently misbehaves if it receives a sigPIPE. Of particular annoyance, it leaves a FIFO hanging around which means that subsequent invocations of FvwmCommand fail. This patch makes FvwmCommand behave much more nicely. SCoTT. :) Index: FvwmCommand.c === RCS file: /home/cvs/fvwm/fvwm/modules/FvwmCommand/FvwmCommand.c,v retrieving revision 1.41 diff -u -r1.41 FvwmCommand.c --- FvwmCommand.c 6 Jul 2003 14:34:07 - 1.41 +++ FvwmCommand.c 28 May 2004 05:15:08 - @@ -56,7 +56,6 @@ void sendit( char *cmd ); void receive( void ); static RETSIGTYPE sig_ttin(int); -/* void sig_pipe( int ); */ static RETSIGTYPE sig_quit(int); void usage(void); int read_f(int fd, char *p, int len); @@ -125,6 +124,7 @@ sigaction(SIGHUP, sigact, NULL); sigaction(SIGQUIT, sigact, NULL); sigaction(SIGTERM, sigact, NULL); +sigaction(SIGPIPE, sigact, NULL); } #else #ifdef USE_BSD_SIGNALS @@ -135,6 +135,7 @@ signal(SIGHUP, sig_quit); signal(SIGQUIT, sig_quit); signal(SIGTERM, sig_quit); + signal(SIGPIPE, sig_quit); signal(SIGTTIN, sig_ttin); signal(SIGTTOU, sig_ttin); #ifdef HAVE_SIGINTERRUPT @@ -142,6 +143,7 @@ siginterrupt(SIGHUP, 1); siginterrupt(SIGQUIT, 1); siginterrupt(SIGTERM, 1); + siginterrupt(SIGPIPE, 1); siginterrupt(SIGTTIN, 0); siginterrupt(SIGTTOU, 0); #endif
Re: EWMH icons
Some apps (for example GVim) appear to have their own icons built in I'm wondering if there's a way to access them somehow? (through the perllib interface of course) Using the WindowList tracker, M_MINI_ICON events have the value ewmh_mini_icon for the name/mini_icon_name field. Not useful to FvwmTabs as I can't load the image. I suppose you mean field named icon_id in M_MINI_ICON in perllib. Ah, I can do a XGetImage($icon_id). Are you sure you can't just embed the mini icon window by its id? Don't think so. There appears to be only one copy of each mini icon (pixmap) in the X server - the same icon_id can be used by multiple windows. You will need to do this anyway, since I think Tk does not support png. Tk supports PNG images just fine - I am currently using them in FvwmTabs. If you are at it, feel free to update FvwmWindowMenu to use WindowList tracker Sure. I'm currently implementing a whole bunch of new features for FvwmTabs - I'll look at FvwmWindowMenu after I release the next version. and to support ewmh mini icons (I guess, you need to patch fvwm menus a bit to support mini-icons by window id, in addition to by name). Ok. SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
EWMH icons
Hi Mikhael, A question for you: Some apps (for example GVim) appear to have their own icons built in I'm wondering if there's a way to access them somehow? (through the perllib interface of course) Using the WindowList tracker, M_MINI_ICON events have the value ewmh_mini_icon for the name/mini_icon_name field. Not useful to FvwmTabs as I can't load the image. I'm trying to associate mini icons with each tab in FvwmTabs. See: http://users.tpg.com.au/users/scottie7/tmp/fvwmtabs.icons.png Any ideas? SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
PATCH: WindowList tracker (perllib)
An updated version of the WindowList tracker. This version fixes clobbering
of fields.
SCoTT. :)
Index: WindowList.pm
===
RCS file: /home/cvs/fvwm/fvwm/perllib/FVWM/Tracker/WindowList.pm,v
retrieving revision 1.4
diff -u -r1.4 WindowList.pm
--- WindowList.pm 25 Oct 2003 03:00:01 - 1.4
+++ WindowList.pm 19 May 2004 14:56:32 -
@@ -1,4 +1,4 @@
-# Copyright (c) 2003 Mikhael Goikhman
+# Copyright (c) 2004 Mikhael Goikhman, Scott Smedley
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -20,11 +20,21 @@
use FVWM::Tracker qw(base);
+my $windowEvents = M_ADD_WINDOW | M_CONFIGURE_WINDOW | M_DESTROY_WINDOW;
+my $nameEvents = M_RES_NAME | M_RES_CLASS | M_WINDOW_NAME | M_VISIBLE_NAME |
M_ICON_NAME;
+my $stackEvents = M_RESTACK | M_RAISE_WINDOW | M_LOWER_WINDOW;
+my $iconEvents = M_ICON_LOCATION | M_ICON_FILE | M_DEFAULTICON | M_MINI_ICON;
+
sub observables ($) {
return [
window added,
window deleted,
window properties updated,
+ window moved,
+ window resized,
+ window name updated,
+ window stack updated,
+ window icon updated,
];
}
@@ -36,41 +46,36 @@
my $self = $class-FVWM::Tracker::new($module);
$self-{options} = [ @options ];
-
return $self;
}
-sub addRequestedInfoHandlers () {
+sub addRequestedInfoHandlers ($$) {
my $self = shift;
- my $handlerC = shift;
- my $handlerD = shift;
- my $handlerP = shift;
+ my $handler = shift;
my $useWInfo = 1;
my $useNames = 1;
my $useStack = 0;
my $useIcons = 0;
- foreach my $option (@{$self-{options}}) {
+ foreach (@{$self-{options}}) {
/^(\!?)winfo$/ and $useWInfo = $1 ne '!';
/^(\!?)names$/ and $useNames = $1 ne '!';
/^(\!?)stack$/ and $useStack = $1 ne '!';
/^(\!?)icons$/ and $useIcons = $1 ne '!';
}
- my $mask1 = 0;
- my $mask2 = 0;
- my $xmask2 = 0;
- $mask1 |= M_ADD_WINDOW | M_CONFIGURE_WINDOW if $useWInfo;
- $mask2 |= M_RES_NAME | M_RES_CLASS | M_WINDOW_NAME | M_VISIBLE_NAME |
M_ICON_NAME
- if $useNames;
- $mask2 |= M_RESTACK | M_RAISE_WINDOW | M_LOWER_WINDOW if $useStack;
- $mask2 |= M_ICON_LOCATION | M_ICON_FILE | M_DEFAULTICON | M_MINI_ICON
- if $useIcons;
- $xmask2 |= MX_VISIBLE_ICON_NAME if $useNames;
-
- $self-addHandler($mask1, $handlerC) if $mask1;
- $self-addHandler(M_DESTROY_WINDOW, $handlerD);
- $self-addHandler($mask2, $handlerP) if $mask2;
- $self-addHandler($xmask2, $handlerP) if $xmask2;
+ my $mask = 0;
+ $mask |= $windowEvents if $useWInfo;
+ $mask |= $nameEvents if $useNames;
+ $mask |= $stackEvents if $useStack;
+ $mask |= $iconEvents if $useIcons;
+
+ # Adding MX_VISIBLE_ICON_NAME to $nameEvents does not work.
+ my $xmask = 0;
+ $xmask |= MX_VISIBLE_ICON_NAME if $useNames;
+
+ $self-addHandler($mask, $handler) if $mask;
+ $self-addHandler($xmask, $handler) if $xmask;
+ $self-addHandler(M_NEW_PAGE, sub { $self-handlerNewPage($_[1]); });
}
sub start ($) {
@@ -78,37 +83,62 @@
$self-{data} = {};
- ### TODO
$self-addRequestedInfoHandlers(sub {
my $event = $_[1];
- $self-calculateInternals($event-args);
- }, sub {
- my $event = $_[1];
- $self-calculateInternals($event-args);
- }, sub {
- my $event = $_[1];
- $self-calculateInternals($event-args);
+ $self-calculateInternals($event);
});
$self-requestWindowListEvents;
-
- ### temporary
- $self-deleteHandlers;
-
my $result = $self-SUPER::start;
-
$self-deleteHandlers;
- ### TODO
$self-addRequestedInfoHandlers(sub {
my $event = $_[1];
- $self-calculateInternals($event-args);
- }, sub {
- my $event = $_[1];
- $self-calculateInternals($event-args);
- }, sub {
- my $event = $_[1];
- $self-calculateInternals($event-args);
+ my ($winId, $oldHash) = $self-calculateInternals($event);
+ return unless defined $winId;
+ my $type = $event-type();
+ if ($type M_ADD_WINDOW)
+ {
+ $self-notify(window added, $winId);
+ }
+ elsif ($type M_CONFIGURE_WINDOW)
+ {
+ $self-notify(window properties updated, $winId,
$oldHash);
+ # The window properties updated observable is very
query mini icon for window (using perllib?)
Hi Mikhael, Is there a way to find out the mini icon associated with a window via the perllib interface? SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: query mini icon for window (using perllib?)
Is there a way to find out the mini icon associated with a window via the perllib interface? I suppose I could issue the following command from within FvwmTabs: WindowId $winId SendToModule FvwmTabs fn setMiniIcon $winId $[w.miniiconfile] but that seems a bit cumbersome ... is there a better way? SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: query mini icon for window (using perllib?)
Hi Mikhael, : Is not this the last (name) field of M_MINI_ICON event? Ah, of course. : Of course you clomber all names in your WindowList patch as far as I : understand it. : I had some idea about how to fix this. Do tell. Would you like me to fix it? SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
PATCH: if - elsif - else - endif syntax
Hi all,
I had a go at attempting to implement if-elsif-else-endif syntax for
FVWM so I can do things like this in my .fvwm2rc file:
(Much more intuitive/maintainable than using PipeRead.)
if xdpyinfo | /bin/grep -q XINERAMA
Echo dual head system!
Xinerama on
XineramaPrimaryScreen 0
DeskTopSize 4x1
else
Echo NOT a dual head system.
DeskTopSize 6x1
endif
if [[ $(hostname) = hamlet.denmark.org ]]
Echo This is SCoTT's home system
elsif hostname | grep -q aao
Echo This is SCoTT's work system
endif
if [ -f someSlackwareFile ]
Echo This is a Slackware system.
elsif [ -f /etc/someDebianFile ]
Echo This is a Debian system.
elsif [ -f /etc/redhat-release ]
Echo This is a RedHat system.
else
Echo No idea what system this is.
endif
if [ $(cat /proc/meminfo | grep ^MemTotal | tr -s ' ' | cut -f2 -d' ') -gt
50 ]
Echo You have more than 0.5GB of RAM
else
Echo You need to upgrade.
endif
Unfortunately I don't know of a way to make this work with FvwmConsole.
Does anyone have any comments, suggestions, criticism, encouragement?
SCoTT. :)
Index: fvwm/read.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/read.c,v
retrieving revision 1.60
diff -u -r1.60 read.c
--- fvwm/read.c 29 Jun 2003 19:53:23 - 1.60
+++ fvwm/read.c 29 Apr 2004 10:44:04 -
@@ -114,25 +114,16 @@
return curr_read_dir;
}
-
-/*
- * Read and execute each line from stream.
- */
-void run_command_stream(
- cond_rc_t *cond_rc, FILE *f, const exec_context_t *exc)
+/* __run_command_stream() - utility function for run_command_stream(). */
+void __run_command_stream(
+ cond_rc_t *cond_rc, FILE *f, const exec_context_t *exc,
+ Bool bInIf, Bool bIfTrue)
{
- char *tline;
+ char *tline, *tmp, *func = __run_command_stream, *cond;
char line[1024];
+ Bool bIgnoreSection = !bIfTrue;
- /* Set close-on-exec flag */
- fcntl(fileno(f), F_SETFD, 1);
-
- /* Update window decorations in case we were called from a menu that
-* has now popped down. */
- handle_all_expose();
-
- tline = fgets(line, (sizeof line) - 1, f);
- while (tline)
+ while (NULL != (tline = fgets(line, (sizeof line) - 1, f)))
{
int l;
while (tline (l = strlen(line)) sizeof(line) l = 2
@@ -150,6 +141,63 @@
{
tline[l - 1] = '\0';
}
+ /* remove leading whitespace */
+ tline = SkipSpaces(tline, NULL, 0);
+ /* ignore blank lines comments. */
+ if (tline == NULL || tline[0] == '\0' || tline[0] == '#')
+ continue;
+
+ tmp = tline;
+ tmp = PeekToken(tmp, cond);
+ if (strcasecmp(tmp, if) == 0)
+ {
+ // fvwm_msg(DBG, func, if-cmd=%s, cond);
+ bIfTrue = !system(cond);
+ // use recursion to allow nested if-statements.
+ __run_command_stream(cond_rc, f, exc, True, bIfTrue);
+ // at this point the complete if-statement has been
handled.
+ // ie. we've parsed the file all the way through to the
+ // matching endif.
+ continue;
+ }
+ else if (strcasecmp(tmp, elsif) == 0)
+ {
+ if (!bInIf)
+ fvwm_msg(ERR, func, \elsif\ not within
if-statement);
+ if (bIfTrue)
+ bIgnoreSection = True;
+ else
+ {
+ // fvwm_msg(DBG, func, elsif-cmd=%s, cond);
+ bIfTrue = !system(cond);
+ bIgnoreSection = !bIfTrue;
+ }
+ continue;
+ }
+ else if (strcasecmp(tmp, else) == 0)
+ {
+ if (!bInIf)
+ fvwm_msg(ERR, func, \else\ not within
if-statement);
+ if (bIfTrue)
+ bIgnoreSection = True;
+ else
+ {
+ bIfTrue = True;
+ bIgnoreSection = False;
+ }
+ continue;
+ }
+ else if (strcasecmp(tmp, endif) == 0)
+ {
+ if (!bInIf)
+ fvwm_msg(ERR, func, \endif\ not within
if-statement);
+ else
+ return;
+ }
+
+ if (bInIf bIgnoreSection)
+ continue;
+
PATCH: implemented WindowList tracker (perllib)
different operations -
here we
+ # try determine if some common operations occur
invoke more
+ # specific observables. This may reduce the amount of
parsing
+ # external modules have to do.
+ my $p = $self-{data}-{$winId};
+ if ($p-{frame_width} != $oldHash-{frame_width} ||
+ $p-{frame_height} != $oldHash-{frame_height})
+ {
+ $self-notify(window resized, $winId,
$oldHash);
+ }
+ elsif ($p-{desk} != $oldHash-{desk} ||
+ $p-{x} != $oldHash-{x} ||
+ $p-{y} != $oldHash-{y})
+ {
+ $self-notify(window moved, $winId, $oldHash);
+ }
+ # We can easily add other specific observables here as
required.
+ }
+ elsif ($type M_DESTROY_WINDOW)
+ {
+ $self-notify(window deleted, $winId, $oldHash);
+ }
+ elsif ($type $nameEvents || $type MX_VISIBLE_ICON_NAME)
+ {
+ $self-notify(window name updated, $winId, $oldHash);
+ }
+ elsif ($type $stackEvents)
+ {
+ $self-notify(window stack updated, $winId, $oldHash);
+ }
+ elsif ($type $iconEvents)
+ {
+ $self-notify(window icon updated, $winId, $oldHash);
+ }
});
return $result;
@@ -116,10 +146,41 @@
sub calculateInternals ($$) {
my $self = shift;
- my $args = shift;
+ my $event = shift;
+ my $args = $event-args;
my $data = $self-{data};
- ### TODO
+ my $winId = $args-{win_id};
+ my $oldHash = undef;
+ if (defined $data-{$winId})
+ {
+ # make a copy of the hash cos we are about to modify it.
+ my %tmp = %{$data-{$winId}};
+ $oldHash = \%tmp;
+ }
+ @{$data-{$winId}}{keys %{$args}} = values %{$args};
+
+ if (defined $args-{frame_x})
+ {
+ # frame_x frame_y are _relative_ coords of the window to the
+ # current page - calculate the _absolute_ coords - x y.
+ my $p = $self-{pageInfo};
+ $data-{$winId}-{x} = $p-{currentPageX} + $args-{frame_x};
+ $data-{$winId}-{y} = $p-{currentPageY} + $args-{frame_y};
+ }
+
+ return wantarray ? ($winId, $oldHash) : $winId;
+}
+
+sub handlerNewPage ($$) {
+ my $self = shift;
+ my $event = shift;
+ my $args = $event-args;
+
+ $self-{pageInfo}-{currentPageX} = $args-{vp_x};
+ $self-{pageInfo}-{currentPageY} = $args-{vp_y};
+ $self-{pageInfo}-{pageWidth} = $args-{vp_width};
+ $self-{pageInfo}-{pageHeight} = $args-{vp_height};
}
sub data ($;$) {
@@ -161,22 +222,27 @@
window added,
window deleted,
window properties updated,
-
-NOT USABLE YET.
+ window moved,
+ window resized,
+ window name updated,
+ window stack updated,
+ window icon updated,
=head1 SYNOPSYS
Using BFVWM::Module $module object (preferably):
-my $windowsTracker = $module-track(ModuleConfig);
+my $windowsTracker = $module-track(WindowList, $options);
my $windows = $windowsTracker-data;
my $windowSizeX = $windows-{$winId}-{'x'};
or:
-my $windowsTracker = $module-track(WindowList);
+my $windowsTracker = $module-track(WindowList, $options);
my $windowSizeX = $windowsTracker-data($winId)-{'x'};
+Default $options string is: !stack !icons names winfo
+
=head1 OVERRIDDEN METHODS
=over 4
@@ -200,7 +266,7 @@
=head1 AUTHOR
-Mikhael Goikhman [EMAIL PROTECTED].
+Mikhael Goikhman [EMAIL PROTECTED], Scott Smedley.
=head1 SEE ALSO
window-specific key-bindings
Dominik, What's the status of my window-specific bindings patch with you? SCoTT. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
WindowList tracker test program
Mikhael,
Here's a simple test program I was using to test the WindowList tracker.
SCoTT. :)
#!/usr/bin/perl -w
# $Id$
use strict;
use lib `fvwm-perllib dir`;
use FVWM::Module;
my $fvwm = new FVWM::Module(Name = 'Scottie', Debug = 2);
# my $tracker = new FVWM::Tracker::WindowList($fvwm);
my $tracker = $fvwm-track('WindowList', !stack !icons names);
$tracker-observe(window added, sub { cb('window added', @_) });
$tracker-observe(window deleted, sub { cb('window deleted', @_) });
$tracker-observe(window moved, sub { cb('window moved', @_) });
$tracker-observe(window resized, sub { cb('window resized', @_) });
# $tracker-observe(window name updated, sub { cb('window name updated', @_)
});
$tracker-observe(window properties updated, sub {
my ($fvwm, $tracker, $z, $winId, $p) = @_;
print(STDERR got window properties updated event: $winId\n);
$fvwm-debug(\t$_: . $p-{$_} . \n)
foreach sort keys %{$p};
});
sub cb
{
my ($eventName, $fvwm, $tracker, $z, $winId, $p) = @_;
print(STDERR got \$eventName\ event for win $winId.\n);
}
$fvwm-eventLoop();
BUG in FVWM::Module (perllib)
Hi Mikhael,
I'm working on the FVWM::Tracker::WindowList code I've discovered a
serious bug. In short calls to deleteHandlers() don't work. (handlers
still exist)
This becomes evident by checking the return value from the call to
FVWM::Module::deleteHandler().
===
RCS file: /home/cvs/fvwm/fvwm/perllib/FVWM/Tracker.pm,v
retrieving revision 1.8
diff -u -r1.8 Tracker.pm
--- Tracker.pm 25 Oct 2003 03:00:00 - 1.8
+++ Tracker.pm 24 Apr 2004 15:12:04 -
@@ -89,7 +89,13 @@
foreach (@$handlerIds) {
next unless defined delete $self-{handlerIds}-{$_};
- $self-{module}-deleteHandler($_) if $self-{module};
+ if ($self-{module})
+ {
+ if ($self-{module}-deleteHandler($_) != 1)
+ {
+ print(STDERR Error deleting handler $_\n);
+ }
+ }
}
}
FVWM::Module::deleteHandler() returns an error because the passed
array ref ($id) is actually a string. (The array ref gets implicitly
converted to a string when it's used as a key-value in a hash. I don't
know of a way to go from the string value of a ref to an actual ref.)
I think the remedy is to use an actual string for handler ids (so
FVWM::Module::addHandler returns $type:$index or similar). I'd code
this up myself but I'm concerned about the impact it will have on the
rest of perllib.
What do you think?
SCoTT. :)
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm-workers in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
window-specific key-bindings patch
Hi Dominik, This post: http://www.hpc.uh.edu/fvwm/archive/0403/msg00054.html contains my modified patch for window-specific key/mouse bindings. I hadn't planned to make any further modifications, but if there's something you'd like me to change just say so ... The initial patch (with an example of usage) is here: http://www.hpc.uh.edu/fvwm/archive/0403/msg0.html SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: PATCH: FakeKeypress
Hi Dominik, : I have applied the patch with some minor reformatting and : renaming - nothing serious. Works like a charm, at least for some : applications (namely, FvwmConsole ignores it). H, it doesn't appear to work with xterms ... Module FvwmConsole -terminal rxvt will make FakeKeypress work with FvwmConsole. SCoTT. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
PATCH: FakeKeypress
Hi all,
Find attached a patch to allow sending of arbitrary key events to
windows. It introduces a new command to FVWM: FakeKeypress
Examples of use:
# save all GVim sessions: Esc:w\n
FvwmCommand 'All (gvim) FakeKeypress press Escape press colon press w press
Return'
# save exit all GVim sessions: Esc:wq\n
FvwmCommand 'All (gvim) FakeKeypress press Escape press colon press w press q
press Return'
# 1984: Do we live under a totalitarian regime?
FvwmCommand 'All (gcalc) FakeKeypress press 2 press plus press 2 press equal'
# Send A to a specific window.
FvwmCommand 'WindowId 0x382 FakeKeypress press A'
SCoTT. :)
--
[EMAIL PROTECTED]
Index: fvwm/builtins.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/builtins.c,v
retrieving revision 1.405
diff -u -r1.405 builtins.c
--- fvwm/builtins.c 19 Feb 2004 09:36:01 - 1.405
+++ fvwm/builtins.c 6 Mar 2004 02:43:25 -
@@ -81,7 +81,7 @@
/* included code files */
/* local types */
-
+typedef enum {FakeMouseEvent, FakeKeyEvent} FakeEventType;
/* forward declarations --- */
/* local variables */
@@ -3718,7 +3718,39 @@
return;
}
-void CMD_FakeClick(F_CMD_ARGS)
+/* Determine which modifiers are required with a keycode to make keysym. */
+static Bool FKeysymToKeycode (Display *dpy, KeySym keysym,
+ unsigned int *keycode, unsigned int *modifiers)
+{
+ int m;
+
+ *keycode = XKeysymToKeycode(dpy, keysym);
+ *modifiers = 0;
+
+ for (m = 0; m = 8; ++m)
+ {
+ KeySym ks = XKeycodeToKeysym(dpy, *keycode, m);
+ if (ks == keysym)
+ {
+ switch (m)
+ {
+ case 0: /* No modifiers */
+ break;
+ case 1: /* Shift modifier */
+ *modifiers |= ShiftMask;
+ break;
+ default:
+ fvwm_msg(ERR, FKeysymToKeycode,
+ Unhandled modifier %d, m);
+ break;
+ }
+ return True;
+ }
+ }
+ return False;
+}
+
+static void fakeEvent(F_CMD_ARGS, FakeEventType type)
{
char *token;
char *optlist[] = {
@@ -3732,19 +3764,19 @@
unsigned int mask = 0;
Window root = Scr.Root;
int maxdepth = 0;
+ static char args[128];
+ strncpy(args, action, sizeof(args) - 1);
+
+ /* get the mask of pressed/released buttons/keys */
+ FQueryPointer(
+ dpy, Scr.Root, root, JunkRoot, JunkX, JunkY, JunkX,
+ JunkY, mask);
- /* get the mask of pressed/released buttons */
- if (FQueryPointer(
- dpy, Scr.Root, root, JunkRoot, JunkX, JunkY, JunkX,
- JunkY, mask) == False)
- {
- /* pointer is on a different screen - that's okay here */
- }
token = PeekToken(action, action);
while (token action)
{
int index = GetTokenIndex(token, optlist, 0, NULL);
- int val;
+ int val, depth;
XEvent e;
Window w;
Window child_w;
@@ -3754,13 +3786,9 @@
int ry = 0;
Bool do_unset;
long add_mask = 0;
+ KeySym keysym = NoSymbol;
XFlush(dpy);
- if (GetIntegerArguments(action, action, val, 1) != 1)
- {
- /* error */
- return;
- }
do_unset = True;
switch (index)
{
@@ -3770,38 +3798,61 @@
/* fall through */
case 2:
case 3:
- /* button press or release */
- if (val = 1 val = NUMBER_OF_MOUSE_BUTTONS)
+ /* key/button press or release */
+ if (type == FakeMouseEvent)
{
- int depth = 1;
-
- w = None;
- child_w = root;
- for (depth = 1; depth != maxdepth
-w != child_w child_w != None;
-depth++)
- {
- w = child_w;
- if (FQueryPointer(
- dpy,
PATCH: binding key/mouse events to individual windows
Hi all,
Find attached a patch to bind key /or mouse events to individual windows.
Syntax is:
Key Tab (FvwmTabs)A C Function NextTab
Now, Ctrl-Tab in an FvwmTabs window invokes the NextTab function whereas
in any other window the key event is passed through to the window with
the focus.
Other examples:
Key V (rxvt)A C Echo ctrl-V-in-RXVT
Key V (xterm)A C Echo ctrl-V-in-XTerm
Key V A C Echo ctrl-V-elsewhere
The only difference is an optional regex-pattern field denoting the
window class/resource/name (appearing in ()-brackets at the _START_
of the context field) that the binding applies to.
This patch is not quite complete - I have not worked out how to
integrate FvwmScript (I've never used it so I don't even know what it
does!) I need to update the man page.
Any feedback would be muchly appreciated.
SCoTT. :)
? libs/.Bindings.c.swp
Index: fvwm/add_window.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/add_window.c,v
retrieving revision 1.360
diff -u -r1.360 add_window.c
--- fvwm/add_window.c 19 Feb 2004 09:36:01 - 1.360
+++ fvwm/add_window.c 27 Feb 2004 12:50:30 -
@@ -1439,15 +1439,15 @@
* the other contexts, new windows have problems when bindings are
* removed. Therefore, grab all keys in a single pass through the
* list. */
- GrabAllWindowKeys(
+ grabAllFWindowKeys(
dpy, FW_W_FRAME(fw), Scr.AllBindings,
C_WINDOW|C_TITLE|C_RALL|C_LALL|C_SIDEBAR, GetUnusedModifiers(),
- True);
+ True, fw);
#endif
- GrabAllWindowKeys(
+ grabAllFWindowKeys(
dpy, FW_W_FRAME(fw), Scr.AllBindings,
C_TITLE|C_RALL|C_LALL|C_SIDEBAR|C_WINDOW, GetUnusedModifiers(),
- True);
+ True, fw);
setup_focus_policy(fw);
return;
Index: fvwm/bindings.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/bindings.c,v
retrieving revision 1.87
diff -u -r1.87 bindings.c
--- fvwm/bindings.c 2 Nov 2003 17:04:44 - 1.87
+++ fvwm/bindings.c 27 Feb 2004 12:50:31 -
@@ -101,6 +101,12 @@
return;
}
+Bool bindingAppliesToFWindow (Binding *b, FvwmWindow *fw)
+{
+ return bindingAppliesToWindow(b, fw-class.res_class,
+ fw-class.res_name, fw-name.name);
+}
+
static int activate_binding(Binding *binding, binding_t type, Bool do_grab)
{
FvwmWindow *t;
@@ -136,6 +142,11 @@
/* grab keys immediately */
for (t = Scr.FvwmRoot.next; t != NULL; t = t-next)
{
+ if (!bindingAppliesToFWindow(binding, t))
+ {
+ continue;
+ }
+
if (!IS_EWMH_DESKTOP(FW_W(t))
(binding-Context (C_WINDOW | C_DECOR))
BIND_IS_KEY_BINDING(type))
@@ -237,8 +248,8 @@
int *nr_left_buttons, int *nr_right_buttons,
unsigned short *buttons_grabbed, Bool is_silent)
{
- char *action, context_string[20], modifier_string[20], *ptr, *token;
- char key_string[201] = ;
+ char *action, context_string[80], modifier_string[20], *ptr, *token;
+ char key_string[201] = , buffer[80], *windowName = NULL;
int button = 0;
int n1=0,n2=0,n3=0;
KeySym keysym = NoSymbol;
@@ -361,7 +372,34 @@
token = PeekToken(ptr, ptr);
if (token != NULL)
{
- n2 = sscanf(token, %19s, context_string);
+ char *p = token;
+ if (*p == '(')
+ {
+ /* A window name has been specified for the binding. */
+ strcpy(buffer, p+1);
+ p = buffer;
+ while (*p != ')')
+ {
+ if (*p == '\0')
+ {
+ if (!is_silent)
+ fvwm_msg(ERR, ParseBinding,
+ Syntax error in line
%s - missing ')', tline);
+ return 0;
+ }
+ ++p;
+ }
+ *p++ = '\0';
+ windowName = buffer;
+ if (*p == '\0')
+ {
+ if (!is_silent)
+ fvwm_msg(ERR, ParseBinding,
+ Syntax error in line %s - no
context specified with window, tline);
+ return 0;
+ }
+ }
+ n2 = sscanf(p, %79s, context_string);
}
token = PeekToken(ptr, action);
if (token != NULL)
@@ -437,7 +475,7 @@
/* BEGIN remove */
PATCH: window-specific key/mouse bindings
Hi all,
Find attached my final patch to bind key /or mouse events to
individual windows.
SCoTT. :)
? fvwm/.fvwm.1.in.swo
? fvwm/.fvwm.1.in.swp
? modules/FvwmScript/.FvwmScript.c.swp
? modules/FvwmScript/.Instructions.c.swp
Index: fvwm/add_window.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/add_window.c,v
retrieving revision 1.360
diff -u -r1.360 add_window.c
--- fvwm/add_window.c 19 Feb 2004 09:36:01 - 1.360
+++ fvwm/add_window.c 2 Mar 2004 05:25:14 -
@@ -1439,15 +1439,15 @@
* the other contexts, new windows have problems when bindings are
* removed. Therefore, grab all keys in a single pass through the
* list. */
- GrabAllWindowKeys(
+ grabAllFWindowKeys(
dpy, FW_W_FRAME(fw), Scr.AllBindings,
C_WINDOW|C_TITLE|C_RALL|C_LALL|C_SIDEBAR, GetUnusedModifiers(),
- True);
+ True, fw);
#endif
- GrabAllWindowKeys(
+ grabAllFWindowKeys(
dpy, FW_W_FRAME(fw), Scr.AllBindings,
C_TITLE|C_RALL|C_LALL|C_SIDEBAR|C_WINDOW, GetUnusedModifiers(),
- True);
+ True, fw);
setup_focus_policy(fw);
return;
Index: fvwm/bindings.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/bindings.c,v
retrieving revision 1.87
diff -u -r1.87 bindings.c
--- fvwm/bindings.c 2 Nov 2003 17:04:44 - 1.87
+++ fvwm/bindings.c 2 Mar 2004 05:25:14 -
@@ -101,6 +101,12 @@
return;
}
+Bool bindingAppliesToFWindow (Binding *b, FvwmWindow *fw)
+{
+ return bindingAppliesToWindow(b, fw-class.res_class,
+ fw-class.res_name, fw-name.name);
+}
+
static int activate_binding(Binding *binding, binding_t type, Bool do_grab)
{
FvwmWindow *t;
@@ -136,6 +142,11 @@
/* grab keys immediately */
for (t = Scr.FvwmRoot.next; t != NULL; t = t-next)
{
+ if (!bindingAppliesToFWindow(binding, t))
+ {
+ continue;
+ }
+
if (!IS_EWMH_DESKTOP(FW_W(t))
(binding-Context (C_WINDOW | C_DECOR))
BIND_IS_KEY_BINDING(type))
@@ -237,8 +248,8 @@
int *nr_left_buttons, int *nr_right_buttons,
unsigned short *buttons_grabbed, Bool is_silent)
{
- char *action, context_string[20], modifier_string[20], *ptr, *token;
- char key_string[201] = ;
+ char *action, context_string[80], modifier_string[20], *ptr, *token;
+ char key_string[201] = , buffer[80], *windowName = NULL;
int button = 0;
int n1=0,n2=0,n3=0;
KeySym keysym = NoSymbol;
@@ -361,7 +372,34 @@
token = PeekToken(ptr, ptr);
if (token != NULL)
{
- n2 = sscanf(token, %19s, context_string);
+ char *p = token;
+ if (*p == '(')
+ {
+ /* A window name has been specified for the binding. */
+ strcpy(buffer, p+1);
+ p = buffer;
+ while (*p != ')')
+ {
+ if (*p == '\0')
+ {
+ if (!is_silent)
+ fvwm_msg(ERR, ParseBinding,
+ Syntax error in line
%s - missing ')', tline);
+ return 0;
+ }
+ ++p;
+ }
+ *p++ = '\0';
+ windowName = buffer;
+ if (*p == '\0')
+ {
+ if (!is_silent)
+ fvwm_msg(ERR, ParseBinding,
+ Syntax error in line %s - no
context specified with window, tline);
+ return 0;
+ }
+ }
+ n2 = sscanf(p, %79s, context_string);
}
token = PeekToken(ptr, action);
if (token != NULL)
@@ -437,7 +475,7 @@
/* BEGIN remove */
CollectBindingList(
dpy, pblist, rmlist, type, STROKE_ARG((void *)stroke)
- button, keysym, modifier, context);
+ button, keysym, modifier, context, windowName);
if (rmlist != NULL)
{
is_binding_removed = True;
@@ -502,7 +540,7 @@
rc = AddBinding(
dpy, pblist, type, STROKE_ARG((void *)stroke)
button, keysym, key_string, modifier, context, (void *)action,
- NULL);
+ NULL, windowName);
return rc;
}
@@ -604,4 +642,23 @@
}
return;
+}
+
+void grabAllFWindowKeys(
+
CheckTwoBindings()
In HandleKeyPress() [file: fvwm/events.c] why is FVWM messing with 2 windows? I'm guessing 1 window is the last focused window the other is the window that _should_ be focussed (may or may not be the same) - is that right? I'm confused as to why it's not possible to decide on _which_ window to lookup bindings for (ie. CheckTwoBindings()). Could someone enlighten me? SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: PATCH: define key-bindings on individual windows
Hi Dominik, Thanks for the feedback, muchly appreciated. In your example, you hold down Ctrl and tap tha Tab key. The modifier mask has the bit for the Ctrl key set. Yep. Now the event is passed on, but when it is processed by fvwm or the receiving application, the real modifier mask may have already changed. I'm not sure what you mean. If the modifier mask changes that implies another event is generated. Are you just saying that the associated KeyRelease event never gets sent to the application? This can lead to erratic behaviour. For example, an application may wait for a KeyRelease event that will never come. Yes, I get the feeling that modifying FVWM to allow KeyRelease events to get through would be a challenging hack at best. Is this a fair synopsis? I guess it would involve remembering which KeyPress events FVWM lets through adding some sort of handler to KeyRelease events to check if there's an associated KeyPress event that got sent through. If there is, send the KeyRelease event through forget the KeyPress event. it's impossible to determine to which window the event has to be sent. There is no guarantee that the top level client window is able to handle key events. Agreed. I'll accept a patch that duplicates the FakeClick syntax (or better: unifies both commands to use the same core loop). I can do that. The application-specific-bindings problem, however, can only be solved in a different way. The binding syntax and code can be enhanced to allow window selection similar to the Style command. Can you please elaborate? + e.xkey.type = KeyPress; + e.xkey.state = 0; // TODO: Ctrl/Shift/Alt/Meta etc. On a slight tangent, do you know how I can get the modifier state from the string name of a keysym? SCoTTie! :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: PATCH: define key-bindings on individual windows
Hi Dominik, I'm not sure what you mean. If the modifier mask changes that implies another event is generated. Are you just saying that the associated KeyRelease event never gets sent to the application? Yes, and in addition, when the event is received, the modifier mask may differ from the actual state of the modifiers. Why would the modifier mask be wrong? I understand the modifier mask to be set to whatever Shift/Ctrl/Alt/etc keys are pressed when the (say) Tab key is pressed. good night! SCoTTie! :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
PATCH: define key-bindings on individual windows
Hi all,
Find attached a patch to FVWM to define key-bindings on individual
windows. (Previously, a key binding had to be defined for ALL windows
or NONE.)
Example .fvwm2rc syntax:
=== BEGIN ===
AddToFunc CtrlTab
+ I Current (FvwmTabs) Function NextTab
+ I Current (!FvwmTabs) SendKeyEvent current
Key Tab A C Function CtrlTab
=== END ===
Here, Ctrl-Tab in an FvwmTabs window will perform a 'NextTab' operation
but in all other windows the Ctrl-Tab keypress is passed through untouched.
(ie. is treated as if there were no FVWM key binding for Ctrl-Tab.)
The patch involves the addition of a new keyword - SendKeyEvent
which basically allows the intercepted key event to be sent through
to a specified window. I hope to generalise SendKeyEvent to be able to
send ANY key event in the near future. (Maybe call it FakeKeypress?)
If this patch is applied I am happy to update the doco.
Comments/criticism most welcome.
SCoTTie! :)
Index: fvwm/builtins.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/builtins.c,v
retrieving revision 1.404
diff -u -r1.404 builtins.c
--- fvwm/builtins.c 24 Jan 2004 23:20:21 - 1.404
+++ fvwm/builtins.c 13 Feb 2004 04:00:23 -
@@ -4252,3 +4252,46 @@
return;
}
+
+void fev_copy_last_event(XEvent *dest); /* libs/FEvent.c */
+
+void CMD_SendKeyEvent(F_CMD_ARGS)
+{
+ char *token;
+ FvwmWindow *fw = exc-w.fw;
+ XEvent e;
+
+ if (fw == NULL)
+ {
+ fvwm_msg(ERR, CMD_SendKeyEvent, No window specified\n);
+ return;
+ }
+
+ fev_copy_last_event(e);
+
+ action = GetNextToken(action, token);
+ if (!token || StrEquals(token, current))
+ {
+ if (e.type != KeyPress)
+ {
+ fvwm_msg(ERR, CMD_SendKeyEvent, Last event wasn't
keypress\n);
+ return;
+ }
+ }
+ else
+ {
+ KeySym keysym = XStringToKeysym(token);
+ // fvwm_msg(DBG, CMD_SendKeyEvent, keysym value: %d\n,
keysym);
+ if (keysym == NoSymbol)
+ {
+ fvwm_msg(ERR, CMD_SendKeyEvent, Unknown keysym:
%s\n, token);
+ return;
+ }
+ e.xkey.type = KeyPress;
+ e.xkey.state = 0; // TODO: Ctrl/Shift/Alt/Meta etc.
+ e.xkey.keycode = XKeysymToKeycode(dpy, keysym);
+ }
+ e.xkey.window = FW_W(fw);
+ FSendEvent(dpy, e.xkey.window, False, KeyPressMask, e);
+ return;
+}
Index: fvwm/commands.h
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/commands.h,v
retrieving revision 1.41
diff -u -r1.41 commands.h
--- fvwm/commands.h 16 Jul 2003 09:10:40 - 1.41
+++ fvwm/commands.h 13 Feb 2004 04:00:23 -
@@ -185,6 +185,7 @@
F_WINDOWID,
F_WINDOW_SHADE,
F_WINDOW_STYLE,
+ F_SEND_KEY_EVENT,
F_END_OF_LIST = 999,
@@ -343,6 +344,7 @@
P(Scroll);
P(Send_ConfigInfo);
P(Send_WindowList);
+P(SendKeyEvent);
P(SendToModule);
P(set_mask);
P(set_nograb_mask);
Index: fvwm/functable.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/functable.c,v
retrieving revision 1.29
diff -u -r1.29 functable.c
--- fvwm/functable.c16 Jul 2003 09:10:40 - 1.29
+++ fvwm/functable.c13 Feb 2004 04:00:24 -
@@ -516,6 +516,10 @@
FUNC_DONT_REPEAT, 0),
/* - Internal, used for module communication */
+ CMD_ENT(sendkeyevent, CMD_SendKeyEvent, F_SEND_KEY_EVENT,
+ FUNC_NEEDS_WINDOW, CRS_SELECT),
+/* - Send a keyboard event to a window */
+
CMD_ENT(sendtomodule, CMD_SendToModule, F_SEND_STRING,
FUNC_DONT_REPEAT, 0),
/* - Send a string (action) to a module */
Re: Menu Screenshot
: Sorry, I must have missed this one. I am going to add some : of your shot soon. Could you please provide a configuration : for the menus as well? Done - see the bottom of the page: http://users.tpg.com.au/users/scottie7/fvwmmenus.html SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Window id of decoration frame
Take a look at: fvwm-perllib --man FVWM::Module::Tk In the SYNOPSIS example I use $top-wrapper-[0]. I'm surprised this works. In a simple test script Perl spewed out an error on a similar line of code. In the end I ended up using: $toplevel-frame(); which gave me what I wanted. frame() wrapper() tend to do counter-intuitive things. At least to my way of thinking. SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Window id of decoration frame
Hi Mikhael, This question is for you, but others might know the answer too. How can I get the window Id of the decoration frame added by FVWM? (via Perl/Tk or X11::Protocol) To elaborate: FVWM adds a decoration frame to each toplevel window. I want to know the window Id of this decoration frame so I can detect 'EnterWindow' events (to fix a focusing race condition in FvwmTabs). After reading the Tk::Wm man page I thought $toplevel-wrapper() would do what I want, but I just get a '0' value. Any help/pointers muchly appreciated. SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Window id of decoration frame
Hi Mikhael, FVWM adds a decoration frame to each toplevel window. I want to know the window Id of this decoration frame so I can detect 'EnterWindow' events (to fix a focusing race condition in FvwmTabs). It appears to be the great-grandparent of the toplevel window. I was able to get it with a trio of XQueryTree() calls, but I'm not sure how portable this is? SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: FvwmTabs v2.1
Hi Mikhael, Thanks for your feedback. It should be in diff -u form to be readable. ok, done. The $VERSION should be numeric, something like: $VERSION = 0.51_2; So anyone still could say: use X11::Protocol 0.51; I couldn't actually get Perl to care about this. (ie. it appears to ignore the version number.) I changed the patch to use 0.51_2 anyway. SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: fvwmtabs 2.0 + packages for cvs version
Hi Xavier, What's up with your email address? Bizarre! :) |If you package FvwmTabs up for Debian, can you send me a paragraph |or 2 that I can put on the FvwmTabs webpage to notify Debian users |what to do? fvwmcvs and X11::protocol packages are ready. i was making a makefile for fvwmtabs. now i need to put up a very small web page on my server and open the port so that apache can actually answer requests. i'll send you the url, and the apt-get url. ppl will need to add it to their sources.list, apt-get update, apt-get install... the usual stuff. i'll test it and send you accurate commands. That would be great, thanks. i'll then work on the next release. (ie fvwmtabs 2.1 and modified X11) That is a good idea. (to make a v2.0 release before v2.1 release) btw, are your changes of X11::protocol in the cpan ? did Stephen answer ? Stephen has not answered. The FvwmTabs website now links to my own patched distribution of X11::Protocol. if not, are your changes compatibles ? (ie will all packages that are using x11::protocol work with your package ?) All changes to X11::Protocol are backwards compatible. Other applications that use X11::Protocol will not notice/care if the patched version is installed. SCoTT. :) -- [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Colorsets tracker experiments.
Hi Mikhael,
This is nice. And it is not such nasty, I can understand it, no problems.
You must be a seasoned Perl/Tk hacker ... like me! :)
Attached is a second (still buggy, but much improved) attempt.
* It doesn't sort colorsets, I added sort { $a = $b } to keys.
* It shows only 12 first colorsets for me, the scrollbar widget should be
added. I should add Style ShowColorsets ResizeHintOverride, otherwise
Tk limits its windows to the screen size.
This version only shows 1 colorset allows you to cycle through
them all. This eliminates these problems.
* It is a bit slow. Yes, it creates 148 colored rectangles in my case,
surrounded by other widgets, but 14 sec even on my slow CPU is many.
SCoTTie has dual AMD1900 so he doesn't notice things like that. :)
This version should have much improved performance.
* There is a problem with refresh, try to WindowShade the window.
Yes, I haven't worked out why this happens yet.
Enjoy!
SCoTT. :)
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm-workers in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
ShowColorsets - missing attachment.
#!/usr/bin/perl -w
# $Id$
use strict;
use lib `fvwm-perllib dir`;
use FVWM::Module::Tk;
use FVWM::Module::Toolkit qw(X11::Protocol Tk Tk::LabFrame);
use constant FIELDS = qw(fg bg hilite shadow fgsh pixmap);
my $main = new MainWindow();
my $x = X11::Protocol-new($main-screen());
$x-event_handler('queue');
my $module = new FVWM::Module::Tk($main, Name = 'ShowColorsets', Debug = 2);
my $tracker = $module-track('Colorsets');
sub nColorsets ()
{
# Colorsets should be numbered sequentially starting from zero,
otherwise
# this logic won't work.
return scalar(keys(%{$tracker-{data}}));
}
my $nC = $main-Label()-pack(-side = 'top');
my $f = $main-Frame()-pack(-side = 'top');
my $l = $f-Label()-pack(-side = 'left');
my %global;
foreach (FIELDS)
{
my $lf = $f-LabFrame(-label = $_,
-labelside =
'acrosstop')-pack(-side = 'left');
$global{colorset}{$_}{frame} = $lf-Frame(-width = 64, -height =
64)-pack();
$global{colorset}{$_}{frameId} =
hex($global{colorset}{$_}{frame}-id());
my $type = ($_ eq 'pixmap' ? 'background_pixmap' : 'background_pixel');
$global{colorset}{$_}{type} = $type;
}
sub showNColorsets ()
{
$nC-configure(-text = There are . nColorsets() . Colorsets.);
}
showNColorsets();
sub showColorset ($)
{
my ($n) = @_;
$global{showCS} = $n;
my $pConfig = $tracker-data($n);
$module-debug(showColorset($n): . join(, , map($_ =
$pConfig-{$_}, keys(%{$pConfig};
$l-configure(-text = Colorset $n:);
foreach (FIELDS)
{
redraw($global{colorset}{$_}{frameId}, $_, $n);
}
}
$tracker-observe(main, sub {
my ($module, $tracker, $z, $nn, $p) = @_;
showColorset($nn) if ($nn == $global{showCS});
showNColorsets();
});
my @p = (-side = 'left', -expand = 1, -fill = 'x');
$main-Button(-text = '', -command = sub { showColorset(($global{showCS} -
1) % nColorsets()); })-pack(@p);
$main-Button(-text = '', -command = sub { showColorset(($global{showCS} +
1) % nColorsets()); })-pack(@p);
$main-Button(-text = 'Refresh', -command = sub {
showColorset($global{showCS}); })-pack(@p);
$main-Button(-text = 'Quit', -command = sub{exit})-pack(@p);
sub redraw ($$$)
{
my ($winId, $field, $n) = @_;
$global{colorset}{$field}{frame}-configure(-bg = $f-cget(-bg));
$x-ChangeWindowAttributes($winId, $global{colorset}{$field}{type} =
$tracker-data($n)-{$field});
$x-req('ClearArea', $winId, (0, 0), 200, 200, 0);
}
sub eventHandler
{
my (%event) = @_;
# $module-debug(Got a $event{name} event for window $event{window}.);
# print(Got a $event{name} event: . join(, , map($_ =
$event{$_}, keys(%event))) . \n);
if ($event{name} eq 'ConfigureNotify' ||
$event{name} eq 'Expose')
{
foreach (FIELDS)
{
if ($global{colorset}{$_}{frameId} == $event{window})
{
redraw($event{window}, $_, $global{showCS});
last;
}
}
}
}
sub XSync ()
{
$x-req('InternAtom', WM_NAME, 0);
}
sub callback
{
XSync();
while (1)
{
my %event = $x-dequeue_event();
last if (!exists($event{name}));
eventHandler(%event);
}
}
$main-repeat(200, \callback);
sub initialise ()
{
$module-debug(Running initialise().);
$main-waitVisibility();
foreach (FIELDS)
{
$x-ChangeWindowAttributes($global{colorset}{$_}{frameId},
event_mask = $x-pack_event_mask('Exposure',
'StructureNotify'));
}
showColorset(0);
}
$main-after(1, \initialise);
$module-eventLoop();
Re: FvwmTabs v1.8
Hi Xavier, On Wed, Jun 18, 2003 at 01:59:06PM -0400, xavier renaut wrote: : Hi, i just discovered your program, : i find it wonderful ! (even without testing :-)) : : Is it possible to make it work with 2.4.15 ? : (i don't mind having a separate config file) The perllib interface (upon which FvwmTabs is built) is rather new, so it's only available in the 2.5.x series. To make FvwmTabs work in the 2.4.x series would involve back-porting most of perllib to 2.4.x. I think this would be a bit premature at this stage as perllib is a work in progress. (ie. there are still sections of unimplemented code.) Perhaps Mikhael can comment? I'm not sure what your reasons are for sticking with 2.4.x releases. If you're worried about stability - don't be, 2.5.x is quite stable. SCoTT. :) -- [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Patch: don't popup debug dialog when it is iconised.
Index: perllib/FVWM/Module/Tk.pm
===
RCS file: /home/cvs/fvwm/fvwm/perllib/FVWM/Module/Tk.pm,v
retrieving revision 1.10
diff -u -r1.10 Tk.pm
--- perllib/FVWM/Module/Tk.pm 15 Jun 2003 01:36:39 - 1.10
+++ perllib/FVWM/Module/Tk.pm 15 Jun 2003 08:11:26 -
@@ -141,8 +141,7 @@
$self-{tkDebugDialog} = $dialog;
$self-{tkDebugTextWg} = $text;
} else {
- # this is annoying, the dialog may contain a check box for this
- $dialog-deiconify();
+ $dialog-deiconify() if ($dialog-state() eq 'withdrawn');
}
my $text = $self-{tkDebugTextWg};
$text-insert('end', $msg\n);
Patch: implement FVWM::Module::Tk::showMessage
? perllib/FVWM/Module/.Tk.pm.swp
Index: perllib/FVWM/Module/Tk.pm
===
RCS file: /home/cvs/fvwm/fvwm/perllib/FVWM/Module/Tk.pm,v
retrieving revision 1.9
diff -u -r1.9 Tk.pm
--- perllib/FVWM/Module/Tk.pm 10 Jun 2003 00:00:17 - 1.9
+++ perllib/FVWM/Module/Tk.pm 13 Jun 2003 14:01:36 -
@@ -75,6 +75,18 @@
$self-send(All ('$title') Close) if $btn eq 'Close All Errors';
}
+sub showMessage ($$;$)
+{
+ my $self = shift;
+ my $msg = shift;
+ my $title = shift || ($self-name . Message);
+
+ $self-topLevel()-messageBox(-icon = 'info',
+ -type = 'ok',
+ -title = $title,
+ -message = $msg);
+}
+
sub topLevel ($) {
return shift-{topLevel};
}
@@ -108,8 +120,8 @@
=head1 DESCRIPTION
The BFVWM::Module::Tk package is a sub-class of BFVWM::Module that
-overloads the methods Bnew, BeventLoop and BshowError to manage
-Tk objects as well. It also adds new methods BtopLevel and BwinId.
+overloads the methods Bnew, BeventLoop, BshowMessage and BshowError
+to manage Tk objects as well. It also adds new methods BtopLevel and
BwinId.
This manual page details only those differences. For details on the
API itself, see LFVWM::Module.
@@ -146,6 +158,10 @@
Exit Module terminates your entire module.
Good for diagnostics of a Tk based module.
+
+=item BshowMessage Imsg [Ititle]
+
+Creates a message window with one Ok button.
=item BtopLevel
Patch: FVWM::Module::Tk::show{Debug,Message}
? perllib/FVWM/.Module.pm.swp
? perllib/FVWM/Module/.Gtk.pm.swp
? perllib/FVWM/Module/.Tk.pm.swp
Index: perllib/FVWM/Module/Tk.pm
===
RCS file: /home/cvs/fvwm/fvwm/perllib/FVWM/Module/Tk.pm,v
retrieving revision 1.9
diff -u -r1.9 Tk.pm
--- perllib/FVWM/Module/Tk.pm 10 Jun 2003 00:00:17 - 1.9
+++ perllib/FVWM/Module/Tk.pm 14 Jun 2003 03:45:17 -
@@ -17,7 +17,7 @@
use 5.004;
use strict;
-use FVWM::Module::Toolkit qw(base Tk Tk::Dialog);
+use FVWM::Module::Toolkit qw(base Tk Tk::Dialog Tk::ROText);
sub new ($$@) {
my $class = shift;
@@ -75,6 +75,72 @@
$self-send(All ('$title') Close) if $btn eq 'Close All Errors';
}
+sub showMessage ($$;$)
+{
+ my $self = shift;
+ my $msg = shift;
+ my $title = shift || ($self-name . Message);
+
+ $self-topLevel()-messageBox(-icon = 'info',
+ -type = 'ok',
+ -title = $title,
+ -message = $msg);
+}
+
+sub showDebug ($$;$)
+{
+ my $self = shift;
+ my $msg = shift;
+ my $title = shift || ($self-name . Debug);
+
+ if (!$self-{tkDebugDialog})
+ {
+ if (!defined $self-topLevel())
+ {
+ # App hasn't been fully created - too early to popup a
dialog.
+ $self-FVWM::Module::showDebug($msg);
+ return;
+ }
+
+ # # Tk's Dialog widgets are too damn inflexible. It's less
+ # hassle to build one from scratch.
+ my $tl = $self-topLevel()-Toplevel(-title = $title);
+ my $top = $tl-Frame()-pack(-expand = 1, -fill = 'both');
+ my $bottom = $tl-Frame()-pack(-expand = 1, -fill = 'x');
+ my $t = $top-Scrolled('ROText',
+ -bg = 'white',
+ -wrap = 'word',
+ -scrollbars = 'oe')-pack();
+
+ $tl-protocol('WM_DELETE_WINDOW', sub { $tl-withdraw(); });
+ my (@pl) = (-side = 'left', -expand = 1, -fill = 'both');
+ $bottom-Button(-text = 'Close', -command = sub {
+ $tl-withdraw(); })-pack(@pl);
+ $bottom-Button(-text = 'Clear', -command = sub {
+ $t-delete('0.0', 'end'); })-pack(@pl);
+ $bottom-Button(-text = 'Save', -command = sub {
+ my $f = $tl-getSaveFile(-title = 'Save' . $title);
+ return if (!defined $f);
+ if (!open(OUT, $f))
+ {
+ $self-showError(Couldn't save $f: $!, 'Save
Error');
+ return;
+ }
+
+ print OUT $t-get('0.0', 'end');
+ close(OUT); })-pack(@pl);
+
+ $self-{tkDebugDialog} = $tl;
+ $self-{tkDebugTextW} = $t;
+ }
+ else
+ {
+ $self-{tkDebugDialog}-deiconify();
+ }
+ $self-{tkDebugTextW}-insert('end', $msg . \n);
+ $self-{tkDebugTextW}-see('end');
+}
+
sub topLevel ($) {
return shift-{topLevel};
}
@@ -108,8 +174,9 @@
=head1 DESCRIPTION
The BFVWM::Module::Tk package is a sub-class of BFVWM::Module that
-overloads the methods Bnew, BeventLoop and BshowError to manage
-Tk objects as well. It also adds new methods BtopLevel and BwinId.
+overloads the methods Bnew, BeventLoop, BshowMessage, BshowDebug and
+BshowError to manage Tk objects as well. It also adds new methods
+BtopLevel and BwinId.
This manual page details only those differences. For details on the
API itself, see LFVWM::Module.
@@ -146,6 +213,21 @@
Exit Module terminates your entire module.
Good for diagnostics of a Tk based module.
+
+=item BshowMessage Imsg [Ititle]
+
+Creates a message window with one Ok button.
+
+=item BshowDebug Imsg [Ititle]
+
+Creates a debug window with 3 buttons - Close, Clear Save.
+All debug messages are added to the debug window.
+
+Close will withdraw the window until the next debug message arrives.
+Clear erases the current contents of the debug window.
+Save will dump the current contents of the debug window to the selected file.
+
+Useful for debugging Tk based modules.
=item BtopLevel
Re: FvwmTabs v1.8
Hi David, : Maybe the size of the buttons should work similiar to mozilla (all : fixed size, when no more space is available all buttons shrink as : needed). Agreed. I'll put it on my TODO list. :And a small bug: it crashes when : you try to add itself as a tab. H, this is a symptom of a focusing bug. I was looking at it last night damn its proving elusive to fix. It's on my TODO list anyway. Thanks for the extra info. SCoTT. :) -- [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FvwmTabs v1.8
Hi David, Finally i have a Dillo with tabs :) Looks nice. hehe! I like Dillo too. Is it possible to change the Font? Sure, I'll make sure there's a config option in the next release. And a small bug: it crashes when you try to add itself as a tab. Hmmm, that's interesting. I thought I guard against this. Certainly if I create a tabber try to add it to itself it reports a: Can't add self to tabber! warning on stdout! Could you elaborate on what you did to trigger this bug? I can't seem to replicate. Thanks, SCoTT. :) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
