FVWM: fvwm quiz
hi all i came across this and thought you might want to try it: http://xteddy.org/fvwmquiz.rbx it's kinda fun - so thanks to the author for it :) sorry if this is old news David
FVWM: fvwm development - and interview idea
Hi all I've noticed a lot of activity with fvwm lately, and was wondering: - is there a way of improving documentation? - what's the roadmap for fvwm's future? - when will fvwm 2.6 be released? Is there a document to describe this? Also, i would like to offer the chance to interview some of the developers of fvwm so i can publish the exchange online - who is best for this please? thanks! David
Re: FVWM: fvwm development - and interview idea
On 21 February 2010 20:23, David Chanters wrote: > Hi all > > I've noticed a lot of activity with fvwm lately, and was wondering: > > - is there a way of improving documentation? > - what's the roadmap for fvwm's future? > - when will fvwm 2.6 be released? > > Is there a document to describe this? > > Also, i would like to offer the chance to interview some of the > developers of fvwm so i can publish the exchange online - who is best > for this please? i was thinking recent development thats been interesting - i know there's the history.php page on fvwm.org already This would be an email interview. David
Re: FVWM: fvwm development - and interview idea
On 23 February 2010 00:16, wrote: > Submit patches. Er, ok. i will try >> - what's the roadmap for fvwm's future? >> - when will fvwm 2.6 be released? >> Is there a document to describe this? > > Look at the TODO file in the source tree. i saw this, but is it accurate for the current dev work? > Thomas Adam has been doing most of the recent development. > Dominik Vogt has probably contributed more than any other single > person to Fvwm and has become the unquestioned expert. > Viktor Griph has been pretty active too. ok - then i will wait and see! thansk David
Re: FVWM: fvwm development - and interview idea
On 23 February 2010 11:11, Thomas Adam wrote: > Which documentation? Something in the man page or larger volumes of > text, such as random guides/tutorials which are floating around on the > 'net? You might want to try and contribute to the FvwmWiki if it's > nothing too specific and you feel you have something you would like to > contribute. i hoped for a tutorial. i will check the wiki then, thank you. > When it's ready. I'm really trying to push to get it out the door > beginning of May, but there's some things still left to do on my own > TODO list, most of which is already referenced in the TODO file in the > source tree --- I do make a habit of updating it as I go along. ;) thank you - i have read this so will wait patiently. David
Re: FVWM: fvwm development - and interview idea
On 23 February 2010 11:08, Thomas Adam wrote: > Ah, I really don't think I can say that I've done much -- I am not > sure what you'd get out of me personally from some sort of interview, > so I'll politely decline. :) that is disappointing as i recall reading things from you on the internet about fvwm. but ok. thanks for telling me :) David
Re: FVWM: fvwm development - and interview idea
On 23 February 2010 00:16, wrote: > Look at the TODO file in the source tree. i did this, and have some questions: - whats the update with the fvwm-convert2.6 script? - according to the TODO file, the only thing remaining is this script? whats outstanding with the convert2.6 script thats holding 2.5.x becoming 2.6.0? Thanks! David
FVWM: fvwm stability in the last few months
hi i've had lots of issues with stability of fvwm on the last few months - crashes from loading menus with background images for the menus. and then today the resize window that usually comes up isnt present - after i did a cvs update early on this morning what's happening with fvwm development? why is it so unstable? this isnt good David
Re: FVWM: fvwm stability in the last few months
On 28 February 2010 23:31, wrote: > David Chanters writes: > >> hi >> >> i've had lots of issues with stability of fvwm on the last few months >> - crashes from loading menus with background images for the menus. >> >> and then today the resize window that usually comes up isnt present - >> after i did a cvs update early on this morning >> >> what's happening with fvwm development? why is it so unstable? this isnt >> good > > No one here can do a thing unless you report the problem. ok - well consider these the problems - -- menus with image as background, when i load a menu with a background image fvwm dies -- the little resize window in the top-left corner doesnt show up anymore this is using the version in cvs - no corefile is ever seen, and ulimit is unlimited David
Re: FVWM: fvwm stability in the last few months
On 28 February 2010 23:50, wrote: > David Chanters writes: > >> On 28 February 2010 23:31, wrote: >>> David Chanters writes: >>> >>>> hi >>>> >>>> i've had lots of issues with stability of fvwm on the last few months >>>> - crashes from loading menus with background images for the menus. >>>> >>>> and then today the resize window that usually comes up isnt present - >>>> after i did a cvs update early on this morning >>>> >>>> what's happening with fvwm development? why is it so unstable? this isnt >>>> good >>> >>> No one here can do a thing unless you report the problem. >> >> ok - well consider these the problems - >> >> -- menus with image as background, when i load a menu with a >> background image fvwm dies > > All my menus have image backgrounds. > We'll need more info. menuface tiledpixmap wavybg.xpm >> -- the little resize window in the top-left corner doesnt show up anymore > > The feedback window is configurable option. > Do you have an "Emulate" command? no - it was working fine until today. >> this is using the version in cvs - no corefile is ever seen, and >> ulimit is unlimited > > If you have a ulimit that is set BEFORE fvwm starts and you have > Fvwm quiting without a core file, there should be something in > your xsession file. it is set _before_ fvwm starts David
Re: FVWM: fvwm stability in the last few months
On 1 March 2010 09:21, Thomas Adam wrote: > On 28 February 2010 23:07, David Chanters > wrote: >> hi >> >> i've had lots of issues with stability of fvwm on the last few months >> - crashes from loading menus with background images for the menus. > > Can you run: > > $ hash -r > $ fvwm --version > > And paste the output? I am *seriously* starting to doubt at this > point that you're running a recent CVS version at all. > >> and then today the resize window that usually comes up isnt present - >> after i did a cvs update early on this morning > > HideGeometryWindow never hi - i was prompted to reply to this. i want to apologize for any confusion caused - i simply had 2.5.26 and cvs fvwm installed and each time was running 2.5.26 - thomas_adam helped me out and all my problems went away - fvwm cvs resolves it all! thanks! David
Re: FVWM: Google Summer Of Code 2010
On 14 March 2010 20:24, Thomas Adam wrote: > On Fri, Jan 29, 2010 at 11:16:38PM +, Thomas Adam wrote: >> Hi all, >> >> So I am going to raise this now, unlike last year where we only had a few >> days to come up with something. > > Alas, this year, it is not to be. Despite my best efforts, I was > unsuccessful in submitting an application on time. > > I am very sorry to have gotten anyone's hopes up on this. As they say: > Better luck next time. > > Sorry all. what happened? i assume you didnt put any effort in this and you let it pass you by? i was looking forward to seeing this grow David
FVWM: initialmapcommand with restart
hi. i see in the cvs changelog for fvwm that the initialmapcommand doesnt now run on restart of fvwm. i liked this feature to remind me a restart had happened and that some windows got "hidden" for free can i have the old feature back? thanks! David
Re: FVWM: initialmapcommand with restart
On 16 March 2010 21:15, Thomas Adam wrote: > No, I am afraid not. Before I fixed it, it was broken. I can't even think i dont like this - can you add an option to keep the old behavior? thanks David
Re: FVWM: initialmapcommand with restart
On 17 March 2010 15:53, Thomas Adam wrote: > On 16 March 2010 21:36, David Chanters wrote: >> On 16 March 2010 21:15, Thomas Adam wrote: >>> No, I am afraid not. Before I fixed it, it was broken. I can't even think >> >> i dont like this - can you add an option to keep the old behavior? > > Sorry, but to revert this would just be wrong -- so the answer is "no". i find this unreasonable. i liked the old behavior because if i had put the window minimized when fvwm restarted it wouldnt be minimized anymore. so please revert this - or get someone else to do it if you cant David
Re: FVWM: initialmapcommand with restart
On 17 March 2010 22:00, wrote: > The way I understand your request, you are asking for Fvwm to > un-minimize windows on a restart. or any window that id used initialmapcommand on - it was useful if id done something to these windows to put them in their original state when restarting fvwm > Fvwm is supposed to restore windows to their previous state and position > on a restart. Doing anything else is a bug. so i keep being told but i think thats unacceptable David
Re: FVWM: initialmapcommand with restart
On 17 March 2010 22:10, David Chanters wrote: > On 17 March 2010 22:00, wrote: >> The way I understand your request, you are asking for Fvwm to >> un-minimize windows on a restart. > > or any window that id used initialmapcommand on - it was useful if id > done something to these windows to put them in their original state > when restarting fvwm > >> Fvwm is supposed to restore windows to their previous state and position >> on a restart. Doing anything else is a bug. > > so i keep being told but i think thats unacceptable also - why isnt anyone peer-reviewing these changes? these decisions need discussion - no one seems to do that - why is any idiot allowed to commit changes like this without discussion? David
Re: FVWM: initialmapcommand with restart
On 17 March 2010 23:16, Thomas Adam wrote: > On Wed, Mar 17, 2010 at 10:10:35PM +0000, David Chanters wrote: >> On 17 March 2010 22:00, wrote: >> > The way I understand your request, you are asking for Fvwm to >> > un-minimize windows on a restart. >> >> or any window that id used initialmapcommand on - it was useful if id >> done something to these windows to put them in their original state >> when restarting fvwm > > Well, you could cheat. If you knew you had groups of windows which you had > toggleable actions on, such as Iconify and Maximize, then you could make use > of State to assign those actions, such as: this works but is a lot of effort for me to do. can you provide an alternative? or just revert to the old behavior? i prefer the old behavior David