Re: What release to do
On Mon, 21 Feb 2005, Bjorn Knutsson wrote: Basically, any key you map in the workspace context becomes unmapped in every other context. 3.6 + my patches work, but none of the 3.7 alphas I've tried do, including alpha5. I do not know why, or what patch caused this, but it seems that it's an interaction between my workspace patch (#1) and later changes. I do My guess, from studying this bug a couple of times, is that both of your patches together triggered some latent bug. Not an uncommon way for difficult bugs to appear, since this means that the bug may be anywhere in the code and not just in the lines changed. 1) Someone else takes ownership of the bug, finds it and fixes it. 2) We start from 3.6, apply patches until it manifests, and then back out the patch that causes the problem until it can be resolved. 3) Back out the workspace patch. 4) For the time being, consider this a Known bug and accept that this (excuse me for saying so) minor patch does not work exactly as expected. As far as I know, this bug does not cause ctwm to crash - does it? Yes, I've looked at alpha5, it's still broken. In the sense that the bug is still there. I did make an effort myself, both to find out what was wrong myself, Keep at it. fairly serious bug at the start of 3.7 that nobody wants to take How serious is this? How many ctwm users use the workspace manager context for keymapping? Don't get me wrong here, I understand that this feature is important to you. However, you have yourself stated that 3.6 + this patch works fine. So as I see it, either you use that combination or you fix the bug. patches for, my suggestion is that we effectively back out that entire blob. Dan, I don't see why you think this is such an unreasonable thing to suggest, given the circumstances, nor why you feel the need to be abusive about it. I assume there was a substancial amount of work involved in getting from 3.6 to 3.7a4. I _know_ the amount of work needed to get from 3.7a4 to 3.7a5. Your suggestion means that we throw all of this away because we have a known bug in the project. Apart from this I have gotten only positive feedback on a5. Most people who tried it said nothing at all - and being a software developer I consider this positive feedback. Disrespecting other people's work is about the most abusive thing I know. Which is why I feel the need to bite back. Actually, my first intuition told me to just unsubscribe from this list and leave ctwm to bleed. Now, can we please stop wasting even more time on this matter. My counter-suggestion is that we move current to 3.7b1. As far as I know we have pretty much taken care of any other a5 issues (such as Rudy's bug). We should of course document the bug discussed above in the appropriate places (manpage and readme?). I'm sure we'll get a lot more issues reported if we try to move to a stable release in a near future, many are prone not to use neither alpha nor beta versions. And this time we should propably issue a few bugfix releases (3.7.1 etc) instead of leaving bunches of patches dangling in void - I suspect this is what really created this mess. Richard, you said you had a few more tickets you wanted to look at before a beta-release? I think I found some minor problem with my late f.changesize patch, but I think we can live with that too in a beta (I'll report this when I have the time and possiblity to reproduce it). Any others against moving to 3.7b1? Regards, //\\ /\ dL - Dan Lilliehorn \ / ASCII ribbon campaign http://www.dL.nu/ X against HTML email [EMAIL PROTECTED] / \
Re: What release to do
On Tue, Feb 22, 2005 at 10:00:16AM +0100 I heard the voice of Michael Widerkrantz, and lo! it spake thus: You realize that the children of the GTK phantom windows (that is, all visible windows in GTK applications) seen from a ctwm point of view has been indistinguishable from transients until 3.7? That is, if you use TransientHasOccupation that will also allow you to use f.occupy on GTK windows. I did. But that causes all sorts of other problems, such as transients then ALWAYS opening in the same workspace they first opened in, instead of the workspace I'm in now. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet
Re: What release to do
On 22 Feb 2005 12:17, Richard Levitte - VMS Whacker wrote: In message [EMAIL PROTECTED] on Tue, 22 Feb 2005 11:49:21 +0100 (CET), [EMAIL PROTECTED] said: dl On Mon, 21 Feb 2005, Bjorn Knutsson wrote: (still talking to Björn) Of course, if the change that is incorrect according to you is among the stuff I got from Claude, you're out of luck. Claude didn't use any SCM, as far as I understood, so that part of history is gone (unless Claude has a really great memory for this kind of thing, after all these years). I think it's in, or related to, Claude's patch. That's why I asked him for his help, and if he could not spare the time, the patch set he used leading up to it. I never even found out if he had them or not. The bug is present in alpha1, which limits the likely culprits the ten changes present in that version, nine if you don't count the workspace patch itself. Of those, everything from the description of the patches to debugging the actual code points at #8, the Xinerama patch as either the cause or the trigger. dl Now, can we please stop wasting even more time on this matter. My dl counter-suggestion is that we move current to 3.7b1. As far as I dl know we have pretty much taken care of any other a5 issues (such dl as Rudy's bug). We should of course document the bug discussed dl above in the appropriate places (manpage and readme?). If someone is willing to write a blob about it, I'd be happy to put it in. There's a perfect place, the BUGS section in ctwm.man. Documenting it is pointless, since the bug renders the workspace patch null and void. Reverting the patch is a better solution, it's not that big. /Björn
Re: What release to do
On Tue, 22 Feb 2005, Bjorn Knutsson wrote: Well, I don't know how you define the word broken, but if you use the workspace environment as documented, CTWM will prevent many programs from working correctly. Hmmm... wait a minute. It renders the keys unusable for _all_ programs, not only ctwm? Meaning that if you press a somewhere outside the workspace context with the config below, nothing will happen? a = : workspace : f.beep This sounds awfully familiar. This is not the same problem I fixed right after the alpha5-release, is it? The one Rudy complained about just about instantly? The one submitted to the repository on June 14th 2004? Did you read the thread following the alpha5 release notification (June 10th 2004) in the archive? http://tigerdyr.wheel.dk/ctwm-archive/ Did you try building the latest version from the cvs archive (you may download it at the bottom of this page: http://repository.lp.se/viewcvs/X/ctwm/) I actually thought we were discussing a completely different problem. Quite frankly CTWM looks pretty pale at the moment Because? Regards, //\\ /\ dL - Dan Lilliehorn \ / ASCII ribbon campaign http://www.dL.nu/ X against HTML email [EMAIL PROTECTED] / \
Re: What release to do (was: [repository.lp.se #104] Bug in ctwm-3.6)
Bjorn Knutsson on wrote... | Honestly, I think 3.7 should just be quitely dropped and we should | restart from 3.6, apply all the bugfix patches and possibly some of | well-tested and known-to-be-OK improvements and call this release 3.8. | | Then, with the new 3.8 as baseline, people can re-submit whatever | patches didn't make it into 3.8. | I argee, ctwm 3.7 was stuffed in to many aspects. I'd also like to see the manpage mark the version number each option was introduced. My twmrc has to deal ctwm versions going way back. As well as twm on a few machines. As such I have lots of to add things using m4 ifdef() statments. EG: I have the following at the top of my twmrc ===8 dnl Convert version number 3.5 or 3.5.2 or 3.7-alpha5 to a 3 digit number dnl for use in ctwm version specific additions. For example: dnlifelse ( eval( CTWM_VERSION = 350 ) ) dnl ifelse( TWM_TYPE, ctwm, [define(CTWM_VERSION, substr(translit( substr(TWM_VERSION, 0, index(TWM_VERSION-, [-])), [.])000, 0, 3) )dnl ],[define(CTWM_VERSION, 0)dnl ])dnl dnl Capitalised version of the window managers name, for use in Menus define( TWM_NAME, translit(TWM_TYPE, [cvt], [CVT]))dnl dnl dnl # [TWM_NAME] = TWM_NAME # [TWM_VERSION] = TWM_VERSION # [CTWM_VERSION] = CTWM_VERSION # ===8 then use things like... ===8 ifelse( TWM_TYPE, ctwm, [dnl #PackNewWindows # try not to overlap with existing windows IgnoreLockModifier# Ignore caplock with all key bindings MenuShadowDepth 2 BorderShadowDepth 3 IconManagerShadowDepth3 ClearShadowContrast 50 # clear shadow for 3D DarkShadowContrast 50 # dark shadow for 3D ifelse( eval( CTWM_VERSION = 360 ), 1, [dnl Only if CTWM Version = 3.6 SloppyFocus # keep focus when on root window #IconifyStyle zoomin # graphical effect for iconify # normal,mosaic,zoomin, # zoomout,sweep ])dnl ctwm 3.6 ifelse( eval( CTWM_VERSION = 370 ), 1, [dnl Only if CTWM Version = 3.7 #NoRaiseOnWarp # when should I raise a win? #NoRaiseOnMove # /\ NoRaiseOnResize # || #RaiseOnClick# raise window when clicked on #RaiseOnClickButton 3# which button? #RaiseDelay10# how long delay raise? ])dnl ctwm 3.7 ])dnl ctwm ===8 Knowing when some option was introduced in the manpage would be a major benifit to me, and probably many others. Anthony Thyssen ( System Programmer )[EMAIL PROTECTED] - Old kiters never die... They just fly away! - Anthony's Home is his Castle http://www.cit.gu.edu.au/~anthony/
Re: What release to do
Matthew D. Fuller on wrote... | ... so I can f.setoccupy Mozilla finally. | I can't find f.setoccupy in the 3.7a5 manpage If it is not documented, it basically may as well not exist for non-development users Actually the manpage could do with a major re-development, especially to organise it into sections like workspace options and functions, perhaps on the website. Anthony Thyssen ( System Programmer )[EMAIL PROTECTED] - A Real Kiter doesn't get annoyed with line tangles. Rather, he finds that sorting them is a relaxing passtime. Line tangles involving many kites are a social occasion. - Anthony's Home is his Castle http://www.cit.gu.edu.au/~anthony/
Re: What release to do
On Wed, Feb 23, 2005 at 10:04:48AM +1000 I heard the voice of Anthony Thyssen, and lo! it spake thus: Matthew D. Fuller on wrote... | ... so I can f.setoccupy Mozilla finally. I can't find f.setoccupy in the 3.7a5 manpage If it is not documented, it basically may as well not exist for non-development users Heck, f.setoccupy doesn't even exist for development users. f.occupy does, though, so everything but my brain should keep working 8-} -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet
Re: What release to do
On 22 Feb 2005 21:04, Dan Lilliehorn wrote: On Tue, 22 Feb 2005, Bjorn Knutsson wrote: Well, I don't know how you define the word broken, but if you use the workspace environment as documented, CTWM will prevent many programs from working correctly. Hmmm... wait a minute. It renders the keys unusable for _all_ programs, not only ctwm? Meaning that if you press a somewhere outside the workspace context with the config below, nothing will happen? Yes. Keys don't even generate KeyPress or KeyRelease events, according to xev. a = : workspace : f.beep This sounds awfully familiar. This is not the same problem I fixed right after the alpha5-release, is it? The one Rudy complained about just about instantly? The one submitted to the repository on June 14th 2004? Did you read the thread following the alpha5 release notification (June 10th 2004) in the archive? http://tigerdyr.wheel.dk/ctwm-archive/ No, I never saw that thread, I have a total of 19 messages for all of last year in my ctwm folder, half of which were spam, and I didn't know I could access the repository until Richard just told me. (Not that the path he gave actually works, but... :-P) Did you try building the latest version from the cvs archive (you may download it at the bottom of this page: http://repository.lp.se/viewcvs/X/ctwm/) Just did, and the CVS version fixes the problem. Kudos on finding it. The line you erased from add_window.c wasn't in my original patch, I never even touched that file. Wonder how it got there... Either way, good work! I actually thought we were discussing a completely different problem. Quite frankly CTWM looks pretty pale at the moment Because? Well, I had not seen much of anything happening in the last year plus. Now I find a bunch of discussions that I hadn't seen, including one about fixing the bug I'd been hunting. Trust me, I'd remembered if I'd seen that one. (Richard, if you have mail server logs showing delivery to me for the last year, I'd be interested - I first thought it was bogofilter, but I keep my spam, and there is nothing there, however, mail to this address bounces around a bit before getting to me.) /Björn
Re: What release to do
On Tue, 22 Feb 2005, Bjorn Knutsson wrote: This is not the same problem I fixed right after the alpha5-release, is it? The one Rudy complained about just about instantly? The one submitted to the repository on June 14th 2004? Did you try building the latest version from the cvs archive (you may Just did, and the CVS version fixes the problem. Kudos on finding it. Great! So I got all wound up over nothing. Sorry for that, the fact that I spent quite some time in May and June fixing a4 and making it useable made me a little touchy on the subject. All this talking about it got me kind of itchy to develop/improve ctwm again. I should get an X workstation running so I can contribute in taking a5 to b1. Positive side-effect, or whatever. Much ado about nothing. Regards, //\\ /\ dL - Dan Lilliehorn \ / ASCII ribbon campaign http://www.dL.nu/ X against HTML email [EMAIL PROTECTED]
