Sticky Icons (was: FVWM: Labelling windows in the FvwmPager)
Lucio Chiappetti wrote: On Wed, 4 Apr 2007, Parv wrote: wrote Lucio Chiappetti thusly... while for moving windows the most frequent way for me is to stick it to all pages and desks, change page, then eventually unstick it. Second choice is drag in the pager. Yet another way, similar to (un)sticking a window, is to iconify the window on the current page; switch to your destination page; uniconify previously iconified window. That's true. I forgot. The fact is that, since when I use fvwm (or any other multi-desktop Wm) I tend to iconize windows much less than I did on older single-page WMs (to make room). Actually I find a bit disturbing the feature that an iconized window belongs to all pages and desktops. My natural expectation would be that an iconized window remain quiescent just on the original page. Is there some fvmw trick to obtain that ? Sure, just _don't_ use the style option StickyIcon ;-) Rainer
Re: FVWM: fvwm, SuSE, backing store
Lucio Chiappetti writes: Having recently moved from Alpha to SuSE Linux (using fvwm as window manager, but kdm to start X as default with SuSE [9.2]) I've noticed a funny behaviour in some applications : (1) RSI IDL plot windows seems not to have any backing store. When they are obscured I lose the obscured part, when I move them to another dekstop page I lose all. (on Alpha they used to behave like that only after several days the server was running, like it had exhausted backing store memory) NB xwininfo returns Backing Store State: Always Save Under State: no I've used IDL on Solaris and Linux, and I always had to tell it to use it's own backing store by putting device,retain=2 into its startup-file. The documentation says the default is to request the server to do it, but that doesn't work. BTW, you have to set it before you open any IDL-windows. Don't know if it has anything to do with FVWM, I don't use other window managers :-) HTH, Rainer -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Function to set dynamic menu title
Ryan Daly writes: Rainer Koehler said: This is such a big mess that I can't keep my mouth shut... No offense, but I think someone should explain to you what you're actually doing here. Sorry for not posting my completed function. That function was obviously just for debugging purposes so I could see that things were working. No problem, and thanks for posting the final (?) function. There are other users here who should see it, and not just some intermediate version. My completed function is as follows: AddToFunc CreateStartMenu + I DestroyMenu StartMenu + I PipeRead 'echo AddToMenu StartMenu `/bin/hostname -s` Title' + I PipeRead '/bin/cat $HOME/.fvwm/.startmenu' Ok, so why don't you use $HOST instead of calling hostname, and why don't you use Read instead of PipeRead to read .startmenu? There might very well be good reasons to do it your way, I just want to know... Rainer -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: init-function
The first time in months I can answer a question here, and Dan is quicker... ;-) Dan Espen writes: Tobias Werth [EMAIL PROTECTED] writes: Hi, in my .fvwm2rc I have inserted an Init Function as follows: AddToFunc InitFunction + I Exec exec ssh-add /dev/null + I Exec exec $HOME/bin/email-notify Both programs grab for the keyboard with ssh-askpass and one of it fails. Can I give some option to the Init Function, so that the commands are process ed sequentially? Exec exec sh -c 'ssh-add /dev/null;$HOME/bin/email-notify' Isn't it a bit overkill to let fvwm start a shell, just to exec sh? I have something similar to Exec ssh-add /dev/null;$HOME/bin/email-notify in my .fvwmrc and it works perfectly (with different commands, but still requiring execution in one shell). By the way, I thought the double-exec was obsolete for years, but the manpage of my fvwm still mentions it. So, what is the current status? Rainer PS: Tobias, the mail to you was meant for the list, sorry. PPS: Dan, the mail for you was meant for the list, too. I should really look at the header more carefully... -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: pointer color
David Albers writes: hi, i have a fairly bone headed question. i am running xdarwin on my apple laptop, solaris on a work station, and linux on my box at home. i use fvwm on all of them, but on the lap top my mouse appears black. this is no good as most of the backgrounds for my shells, emacs, etc, are black. i can't figure out how to change the color of my mouse/pointer in my .fvwm file. please help, dave Sounds exactly like the problem a friend of mine had on his mac. It was caused by a bug in the Xserver and fixed by installing a new version. Fvwm can't do anything about it. Hope this helps, Rainer -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: FvwmIconMan: Can't set geometry
f [EMAIL PROTECTED] net writes: I'd like to simply start my session with a FvwmIconMan on my screen. However, it appears always in the upper left corner. (It is not swallowed into FvwmButtons.) How do I place it elsewhere? Nothing of the following was successful (these values are just to test it): *FvwmIconMan: Geometry 100x100+50+50 FvwmIconMan -geometry 100x100+50+50 Style FvwmIconMan Geometry 100x100+50+50 You could try reading the manpage of FvwmIconMan or just search it for geometry. I admit it's not very clear, but at least it tells you that Geometry is not a valid option, while buttongeometry and managergeometry are. Of course, reading a manpage can be dangerous, because you might spend hours trying all the fancy configurable things you discover in it :-) So, to protect you from this danger, here are the relevant lines of my config: *FvwmIconMan*managergeometry1x0+0+272 *FvwmIconMan*buttongeometry 193x0 Disclaimer: The syntax is obsolete, because I still use 2.2 at work, and didn't bother to update the fvwm2rc on my laptop running 2.4. I didn't want to tell you something I haven't tested myself. Hope this helps, Rainer -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: .fvwm2rc syntax guide?
f [EMAIL PROTECTED] net writes: On Sat, 24 Aug 2002 19:15:05 -0700 Rainer Koehler [EMAIL PROTECTED] wrote: So, why don't you go ahead and write something like that? [...] Also, I don't think the fvwm developers would be very good at writing a tutorial for beginners. Concidering myself a newbie I'd like to do that. The only problem is: a newbie knows the problems - but can't provide the solutions. You can ask the questions here and collect the answers. I'm always surprised how patiently the developers answer the same questions over and over again (except that after a while, all my keybindings stop working :-) Questions with concrete wishes are much easier to answer than I fiddled with the config file for hours and it didn't work. I don't think you'll spam the man page if you insert a short section for the main issues beginners have. And, my favorite way to do it is nearly already done: Look at man FvwmIconMan, Configuration Options Reference Chart. Add one single column to it with an example command and there you go. Hmm, I think the same table for fvwm itself would be sevaral pages long, but I agree, it would be a good idea to have something like that. Look, isn't fvwm2 worth it to forget maybe tine a little bit about the guide lines of man pages and follow the wishes of many beginners to fvwm2 - since they'll all start typing m-a-n instead of querying goole for some tutorial? Well, I consider someone who knows about man and is willing to use it no longer a real newbie :-) Another post here raised suspicion that someone read the manpage on the web and tried to apply it to the fvwm on his system (without success because he uses a different version). So maybe it would be better to write it in HTML. For many, it might be easier to write something in HTML than to write a manpage. But the format doesnt really matter, what's missing is the content! I would vote for splitting the manpage into some kind of introduction or a tutorial and a reference manual, but so far, only the reference part exists. Please excuse my passion - it's just the passion for fvwm2. I think we share that passion, that's why I get a bit angry when someone complains about the manpage without giving the impression that he is willing to do something about it. Cheers, Rainer -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: .fvwm2rc syntax guide?
[EMAIL PROTECTED] de writes: On Fri, 23 Aug 2002 22:01:27 -0500 Len Philpot [EMAIL PROTECTED] wrote: [...] never get there. I'm having the do *EVERYTHIHG* by trial and error, since the man page is so vague (or maybe I'm just stupid...?). Hi, I just wanted to add that fvwm2 is a great window manager - but I agree that the man page is hard to read and understand! So here is a little suggestion to improve the man page: Insert a section (at the beginning) which deals with the basic configuration faqs - and show examples right there. Most important: Let this section be organized by *the point of view of a beginner* who just wants to change color of background, change the root menu, change the window styles. If he passed that he will have enough starting enegery to go through the rest of the man page. ;-) So, why don't you go ahead and write something like that? With this ongoing discussion about the manpage, I'd like to add my two cents (US or Euro - I don't know). I've been using fvwm longer than I can remember. However, I can remember the times when it was maintained by Rob Nation, and I think there's still a tape with my config-file for fvwm 1.xy, although I doubt that I can find a drive to read it. The thing I like most about fvwm is it nearly infinite flexibility and configurability. That comes with a price, the documentation is only for someone who is willing to read a whole reference manual before he starts using the program. But even the best documentation would be long (probably too long for newbies) and difficult to understand because for many things you have to understand the whole picture (which sometimes includes more than fvwm). And frankly, I don't want the fvwm developers to write documentation for beginning. I want them to fix old bugs and add new features so I can get more out of it. That works pretty well so far. If fvwm came with a graphical configuration tool, I could as well use Gnome, KDE, or M$-Windows. Also, I don't think the fvwm developers would be very good at writing a tutorial for beginners. You have to remember how it was when you were a newby to write something a newby can understand. It would probably be best if someone who wrote or modified his first fvwm2rc not too long ago would write a few paragraphs about what he wanted and how he achieved it. I'm sure the developers would be willing to comment on it and give advice if there are better ways to achieve the desired behavior. But it's *YOU*, the newbies out there who know what the confusing things are, not the fvwm developers! Fvwm and its documentation are open source, if there's something you don't like, fix it. If you are able to edit your fvwm2rc, you should be able to write a little text about it, you don't need a degree in computer science for that. Thank you for your attention, I go back to lurking now. Rainer -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: fvwm2rc + restart
John Smith writes: Hey, I was thinking about something as I was rewriting part of my configuration, and I thought it would be neat if there were an option in fvwm2 where you can have fvwm2 automatically reload when you change the .fvwm2rc. You were already told why it is not a good idea to have fvwm read its config-file every time it changes. This doesn't mean it's not possible to edit it and reread it when you are done. Here is my function to do that: DestroyFunc EditFvwmrc AddToFunc EditFvwmrc I Exec edit_fvwmrc.tk +I Wait edit_fvwmrc.tk +I echo Re-reading fvwmrc +I Read .fvwm2rc Edit_fvwmrc.tk is a little tcl/tk-script to edit the .fvwm2rc and open a window to tell fvwm when we are ready: - - #!/bin/sh # -*- Mode: tcl -*- # # edit_fvwmrc.tk # Created: Tue Apr 2 17:54:21 2002 by [EMAIL PROTECTED] # Last Change: Tue Apr 2 18:42:34 2002 # # use from within fvwm 2.2 to edit the .fvwm2rc and # open a window to trigger a wait command in fvwm # #\ exec wish $0 $@ exec gnuclient_emacs $env(HOME)/.fvwm2rc update exit - - (Gnuclient_emacs is my command to tell a running emacs that we want to edit a file) I hate scripts that have more comments than code, but my attempts to squeeze everything into one Exec-line within the fvwmrc resulted only in crashes (Of course, fvwm loads the edited fvwmrc when it is restarted after the crash, but I don't think that's what you want :) HTH Rainer -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
